linux系统漏洞？linux有必要学吗

各位老铁们好，相信很多人对linux系统漏洞都不是特别的了解，因此呢，今天就来为大家分享下关于linux系统漏洞以及linux有必要学吗的问题知识，还望可以帮助大家，解决大家的一些困惑，下面一起来看看吧！

一次Linux系统被服务器被rootkit攻击的处理思路和处理过程

IT行业发展到现在，安全问题已经变得至关重要，从最近的“棱镜门”事件中，折射出了很多安全问题，信息安全问题已变得刻不容缓，而做为运维人员，就必须了解一些安全运维准则，同时，要保护自己所负责的业务，首先要站在攻击者的角度思考问题，修补任何潜在的威胁和漏洞。

一次Linux被入侵后的分析

下面通过一个案例介绍下当一个服务器被rootkit入侵后的处理思路和处理过程，rootkit攻击是Linux系统下最常见的攻击手段和攻击方式。

1、受攻击现象

这是一台客户的门户网站服务器，托管在电信机房，客户接到电信的通知：由于此服务器持续对外发送数据包，导致100M带宽耗尽，于是电信就切断了此服务器的网络。此服务器是Centos5.5版本，对外开放了80、22端口。

从客户那里了解到，网站的访问量并不大，所以带宽占用也不会太高，而耗尽100M的带宽是绝对不可能的，那么极有可能是服务器遭受了流量攻击，于是登录服务器做详细的检测。

2、初步分析

在电信人员的配合下通过交换机对该服务器的网络流量进行了检测，发现该主机确实存在对外80端口的扫描流量，于是登录系统通过“netstat–an”命令对系统开启的端口进行检查，可奇怪的是，没有发现任何与80端口相关的网络连接。接着使用“ps–ef”、“top”等命令也没有发现任何可疑的进程。于是怀疑系统是否被植入了rootkit。

为了证明系统是否被植入了rootkit，我们将网站服务器下的ps、top等命令与之前备份的同版本可信操作系统命令做了md5sum校验，结果发现网站服务器下的这两个命令确实被修改过，由此断定，此服务器已经被入侵并且安装了rootkit级别的后门程序。

3、断网分析系统

由于服务器不停向外发包，因此，首先要做的就是将此服务器断开网络，然后分析系统日志，寻找攻击源。但是系统命令已经被替换掉了，如果继续在该系统上执行操作将变得不可信，这里可以通过两种方法来避免这种情况，第一种方法是将此服务器的硬盘取下来挂载到另外一台安全的主机上进行分析，另一种方式就是从一个同版本可信操作系统下拷贝所有命令到这个入侵服务器下某个路径，然后在执行命令的时候指定此命令的完整路径即可，这里采用第二种方法。

我们首先查看了系统的登录日志，查看是否有可疑登录信息，执行如下命令：

more/var/log/secure|grep Accepted

通过对命令输出的查看，有一条日志引起了我们的怀疑：

Oct 3 03:10:25 webserver sshd[20701]: Accepted password for mail from 62.17.163.186 port 53349 ssh2

这条日志显示在10月3号的凌晨3点10分，有个mail帐号从62.17.163.186这个IP成功登录了系统，mail是系统的内置帐号，默认情况下是无法执行登录操作的，而62.17.163.186这个IP，经过查证，是来自爱尔兰的一个地址。从mail帐号登录的时间来看，早于此网站服务器遭受攻击的时间。

接着查看一下系统密码文件/etc/shadow，又发现可疑信息：

mail:$1$kCEd3yD6$W1evaY5BMPQIqfTwTVJiX1:15400:0:99999:7:::

很明显，mail帐号已经被设置了密码，并且被修改为可远程登录，之所以使用mail帐号，猜想可能是因为入侵者想留下一个隐蔽的帐号，以方便日后再次登录系统。

然后继续查看其他系统日志，如/var/log/messages、/var/log/wtmp均为空文件，可见，入侵者已经清理了系统日志文件，至于为何没有清空/var/log/secure文件，就不得而知了。

4、寻找攻击源

到目前为止，我们所知道的情况是，有个mail帐号曾经登录过系统，但是为何会导致此网站服务器持续对外发送数据包呢？必须要找到对应的攻击源，通过替换到此服务器上的ps命令查看系统目前运行的进程，又发现了新的可疑：

nobody  22765    1 6 Sep29?       4-00:11:58.t

这个.t程序是什么呢，继续执行top命令，结果如下：

PID USER   PR NI VIRT RES SHR S %CPU%MEM   TIME+ COMMAND

22765 nobody 15 0  1740m 1362m 1228 S 98.3   91.5     2892:19  .t

从输出可知，这个t程序已经运行了4天左右，运行这个程序的是nobody用户，并且这个t程序消耗了大量的内存和cpu，这也是之前客户反映的网站服务器异常缓慢的原因，从这个输出，我们得到了t程序的进程PID为22765，接下来根据PID查找下执行程序的路径在哪里：

进入内存目录，查看对应PID目录下exe文件的信息：

[root@webserver~]#/mnt/bin/ls-al/proc/22765/exe

lrwxrwxrwx 1 root root 0 Sep 29 22:09/proc/22765/exe-/var/tmp/…/apa/t

这样就找到了进程对应的完整程序执行路径，这个路径很隐蔽，由于/var/tmp目录默认情况下任何用户可读性，而入侵者就是利用这个漏洞在/var/tmp目录下创建了一个“…”的目录，而在这个目录下隐藏着攻击的程序源，进入/var/tmp/…/目录，发现了一些列入侵者放置的rootkit文件，列表如下：

[root@webserver...]#/mnt/bin/ls-al

drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 apa

-rw-r--r-- 1 nobody nobody    0 Sep 29 22:09 apa.tgz

drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 caca

drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 haha

-rw-r--r-- 1 nobody nobody     0Sep 29 22:10 kk.tar.gz-

rwxr-xr-x 1 nobody nobody     0 Sep 29 22:10 login

-rw-r--r-- 1 nobody nobody     0 Sep 29 22:10 login.tgz

-rwxr-xr-x 1 nobody nobody     0 Sep 29 22:10 z

通过对这些文件的分析，基本判断这就是我们要找的程序攻击源，其中：

1）、z程序是用来清除系统日志等相关信息的，例如执行：

./z 62.17.163.186

这条命令执行后，系统中所有与62.17.163.186有关的日志将全部被清除掉。

2）、在apa目录下有个后门程序t，这个就是之前在系统中看到的，运行此程序后，此程序会自动去读apa目录下的ip这个文件，而ip这个文件记录了各种ip地址信息，猜想这个t程序应该是去扫描ip文件中记录的所有ip信息，进而获取远程主机的权限，可见这个网站服务器已经是入侵者的一个肉鸡了。

3）、haha目录里面放置的就是用来替换系统相关命令的程序，也就是这个目录下的程序使我们无法看到操作系统的异常情况。

4）、login程序就是用来替换系统登录程序的木马程序，此程序还可以记录登录帐号和密码。

5、查找攻击原因

到这里为止，服务器上遭受的攻击已经基本清晰了，但是入侵者是如何侵入这台服务器的呢？这个问题很重要，一定要找到入侵的根源，才能从根本上封堵漏洞。

为了弄清楚入侵者是如何进入服务器的，需要了解下此服务器的软件环境，这台服务器是一个基于java的web服务器，安装的软件有apache2.0.63、tomcat5.5，apache和tomcat之间通过mod_jk模块进行集成，apache对外开放80端口，由于tomcat没有对外开放端口，所以将问题集中到apache上面。

通过查看apache的配置发现，apache仅仅处理些静态资源请求，而网页也以静态页面居多，所以通过网页方式入侵系统可能性不大，既然漏洞可能来自于apache，那么尝试查看apache日志，也许能发现一些可疑的访问痕迹，通过查看access.log文件，发现了如下信息：

62.17.163.186-- [29/Sep/2013:22:17:06+0800]"GET HTTP/1.0" 200 12333"-""Mozilla/5.0(Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1) Gecko/20121010 Firefox/2.0"

62.17.163.186-- [29/Sep/213:22:17:35+0800]"GET HTTP/1.0" 200 1626"-""Mozilla/5.0(Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1) Gecko/20121010 Firefox/2.0"

至此，发现了漏洞的根源，原来是awstats.pl脚本中configdir的一个漏洞，通过了解此服务器的应用，客户确实是通过一个Awstats的开源插件来做网页访问统计，通过这个漏洞，攻击者可以直接在浏览器上操作服务器，例如查看进程、创建目录等。通过上面第二条日志可以看出，攻击者正常浏览器执行切换到/var/tmp/.../haha目录的操作。

这个脚本漏洞挺可怕的，不过在Awstats官网也早已给出了修补的方法，对于这个漏洞，修复方法很简单，打开awstats.pl文件，找到如下信息：

if($QueryString=~/configdir=([^]+)/i)

{

$DirConfig=DecodeEncodedString("$1");

}

修改为如下即可：

if($QueryString=~/configdir=([^]+)/i)

{

$DirConfig=DecodeEncodedString("$1");

$DirConfig=~tr/a-z0-9_/-///./a-z0-9_/-///./cd;

}

6、揭开谜团

通过上面逐步分析和介绍，此服务遭受入侵的原因和过程已经非常清楚了，大致过程如下：

（1）攻击者通过Awstats脚本awstats.pl文件的漏洞进入了系统，在/var/tmp目录下创建了隐藏目录，然后将rootkit后门文件传到这个路径下。

（2）攻击者通过植入后门程序，获取了系统超级用户权限，进而控制了这台服务器，通过这台服务器向外发包。

（3）攻击者的IP地址62.17.163.186可能是通过代理过来的，也可能是攻击者控制的其他肉鸡服务器。

（4）攻击者为了永久控制这台机器，修改了系统默认帐号mail的信息，将mail帐号变为可登录，并且设置了mail帐号的密码。

（5）攻击者在完成攻击后，通过后门程序自动清理了系统访问日志，毁灭了证据。

通过对这个入侵过程的分析，发现入侵者的手段还是非常简单和普遍的，虽然入侵者删除了系统的一些日志，但是还是留下了很多可查的踪迹，其实还可以查看用户下的.bash_history文件，这个文件是用户操作命令的历史记录。

7、如何恢复网站

由于系统已经文件被更改和替换，此系统已经变得完全不可信，因此建议备份网站数据，重新安装系统，基本步骤如下：

（1）安装稳定版本的操作系统，删除系统默认的并且不需要的用户。

（2）系统登录方式改为公钥认证方式，避开密码认证的缺陷。

（3）安装更高版本的apache和最新稳定版本的Awstats程序。

（4）使用Linux下的Tcp_Wrappers防火墙，限制ssh登录的源地址。

Linux系统主机服务器被入侵后怎么办

！下面大家还是跟着我们5636网吧联盟的网吧系统栏目一起去看看吧！

我们可以试试这样来做：

1.第一时间拨掉网线，这可以说是最安全的断开链接的方法，除了保护自己外,也可能保护同网段的其他主机！

(1)分析登录文件的话:我们可以通过分析一些主要的登录文件找到对方的IP以及可能出现的漏洞.一般分析的文件为:/var/log/messages和/var/log/secure文件.还可以使用last命令找出最后一个登录者的信息

(2)检查主机开放的服务:每个服务都有漏洞或不该启动的增强型或测试型功能.找出系统上的服务,逐个检查服务是否有漏洞或设置上的失误.

(3)重要数据备份，就是非Linux上的原有数据.如/etc/passwd,/etc/shadow,WWW网页的数据,/home里的用户文件,至于/etc/*,/usr/,/var等目录下的数据就不要备份了.

(4)系统重装，这个重要的是选择合适的包,不要将所有的包都安装.

(5)包漏洞修补，安装后,要立即更新系统包,更新后再设置防火墙机制,同时关闭一些不必要的服务,最后才插上网线

(6)关闭或卸载不需要的服务，一般启动的服务越少,系统入侵的可能性就越低

(7)数据恢复与恢复服务设置，备份的数据要复制回系统,然后将提供的服务再次开放(8)最后将主机开放到网络上

Linux服务器常见的安全漏洞有哪些

linux管理常见错误一：随意许可，原因是不理解许可

如果对许可配置不当，就会给黑客留下机会。处理许可问题的最简单方法是使用所谓的RWE方法，即Read(读取)、Write(写入)、Execute(执行)。假设你想让一个用户能够读取一个文件但不能写入文件。为此，你可以执行：chmod

u+w,u-rx文件名，一些新用户可能会看到一个错误，说他们没有使用文件的许可，因此他们就使用了：Chmod 777

文件名，以为这样能够避免问题。但这样做实际上会导致更多的问题，因为它给了文件的可执行的权限。

记住这一点：777将一个文件的读取、写入、执行的许可给了所有用户，666将一个文件的读取、写入权限给了所有用户，而555将文件的读取、执行权限给了所有用户，还有444、333、222、111等等。

linux管理常见错误二：忽视更新

这并不是说Linux管理员缺乏技巧。不过，许多Linux管理员在运行了Linux之后，以为日后就无事可做了，以为它安全可靠。其实，新的更新可以为一些新的漏洞打上补丁。维持更新可以在一个易受损的系统与一个安全的系统之间构造分水岭。Linux的安全来自于不断地维护。为了实现安全性，为了使用一些新的特性和稳定性，任何管理员都应当跟上Linux的更新步伐。

linux管理常见错误三：不经过严格审核，从多种渠道下载安装各种类型的应用程序

乍看起来，这也许是一个不错的主意。如果你在运行Ubuntu,你会知道包管理程序使用的是。deb软件包。不过，你找到的许多应用程序是以源代码的形式提供的。没有问题吗?这些程序安装后也许能够正常工作。但是你为什么不能随意安装程序呢?道理很简单，如果你以源的形式安装了程序，那么，你的软件包管理系统将无法跟踪你所安装的东西。

因此，在程序包A(以源的形式安装)依赖于程序包B(从一个。deb库安装的)，而软件包B是从更新管理器更新的时候，会发生什么事情呢?程序包A可能运行，也可能无法运行。不过，如果程序包A和B都从。deb库安装的话，二者都能运行的机会将更高。此外，在所有的程序包都来自于同样的二进制类型时，更新程序包将更为容易。

linux管理常见错误四：将服务器启动进入到X

在一台机器是专用服务器时，你可能会想到安装X,这样一些管理任务就会简单一些。不过，这并不意味着用户需要将服务器启动进入到X.这样会浪费珍贵的内存和CPU资源。相反地，你应当在级别3上停止启动过程，进入命令行模式。这样做不但会将所有的资源留给服务器，而且还会防止泄露机器的机密。要登录到X,用户只需要以命令行方式登录，然后键入startx进入到桌面。

linux管理常见错误五：糟糕的口令

记住，root

的口令通常是linux王国的关键。所以为什么要让root的口令那么容易被破解呢?保障你的用户口令的健壮性至关重要。如果你的口令比较长，且难于记忆，可将这个口令存放在一个可被加密的位置。在需要这个口令时，可用解密软件解开这个口令使用之。

linux管理常见错误六：没有备份关键的配置文件

许多管理员都有这样的体会，在升级到某个X版本，如X11之后，却发现新版本破坏了你的xorg.conf配置文件，以至于你再也无法使用X?建议你在升级X之前，先对以前的/etc/x11/xorg.conf作一个备份，以免升级失败。当然，X的升级程序会设法为用户备份xorg.conf文件，但它却在/etc/x11目录内备份。即使这种备份看起来不错，你最好还是自己做一个备份吧。笔者的一个习惯是将其备份到/root目录中，这样，用户就可以知道只有根(root)用户能够访问此文件。记住，安全第一。这里的方法也适用于其它的关键备份，如Samba、Apache、Mysql等。

linux管理常见错误七：忽视日志文件

/var/log的存在是有理由的。这是存放所有的日志文件的唯一位置。在发生问题时，你首先需要看一下这里。检查安全问题，可看一下/var/log/secure.笔者看的第一个位置是/var/log/messages.这个日志文件保存着所有的一般性错误。在此文件中，你可以得到关于网络、媒体变更等消息。在管理一台机器时，用户可以使用某个第三方的应用程序，如logwatch,这样就可以创建为用户创建基于/var/log文件的各种报告。

linux管理常见错误八：没有安装一个可正常运行的内核

你可能不会在一台机器上安装10个以上的内核。但你需要更新内核，这种更新并没有删除以前的内核。你是怎么做的呢?你一直保持使用最近的可正常工作的内核。假设你目前正常工作的内核是2.6.22,而2.6.20是备份内核。如果你更新到2.6.26,而在新内核中一切都工作正常，你就可以删除2.6.20了。

linux管理常见错误九：逃避使用命令行

恐怕很少有人愿意记住那么多命令。在大多数情况下，图形用户界面是许多人的最爱。不过，有时，命令行使用起来更加容易、快捷、安全、可靠。逃避使用命令行是Linux管理的大忌。管理员至少应当理解命令行是如何工作的，至少还要掌握一些重要的管理命令。

linux管理常见错误十：以根用户身份登录

这是一种很危险的错误。如果用户需要根特权来执行或配置一个应用程序，可以在一个标准的用户账户中使用su切换到root用户。登录到root为什么不是一件好事儿?在用户以标准用户身份登录时，所有正在运行的X应用程序仍拥有仅限于此用户的访问权。如果用户以根用户身份登录，X就拥有了root的许可。这就会导致两个问题，一、如果用户由GUI犯了一个大错，这个错误对系统来说，有可能是一个巨大的灾难。二、以根用户的身份运行X使得系统更易于遭受攻击。