分类 企业安全 下的文章

osquery源码解读之分析process_open_socket

说明

上篇文章主要是对shell_history的实现进行了分析。通过分析可以发现,osquery良好的设计使得源码简单易读。shell_history的整体实现也比较简单,通过读取并解析.bash_history中的内容,获得用户输入的历史命令。本文分析的是process_open_sockets,相比较而言实现更加复杂,对Linux也需要有更深的了解。

使用说明

首先查看process_open_sockets表的定义:

table_name("process_open_sockets")
description("Processes which have open network sockets on the system.")
schema([
    Column("pid", INTEGER, "Process (or thread) ID", index=True),
    Column("fd", BIGINT, "Socket file descriptor number"),
    Column("socket", BIGINT, "Socket handle or inode number"),
    Column("family", INTEGER, "Network protocol (IPv4, IPv6)"),
    Column("protocol", INTEGER, "Transport protocol (TCP/UDP)"),
    Column("local_address", TEXT, "Socket local address"),
    Column("remote_address", TEXT, "Socket remote address"),
    Column("local_port", INTEGER, "Socket local port"),
    Column("remote_port", INTEGER, "Socket remote port"),
    Column("path", TEXT, "For UNIX sockets (family=AF_UNIX), the domain path"),
])
extended_schema(lambda: LINUX() or DARWIN(), [
    Column("state", TEXT, "TCP socket state"),
])
extended_schema(LINUX, [
    Column("net_namespace", TEXT, "The inode number of the network namespace"),
])
implementation("system/process_open_sockets@genOpenSockets")
examples([
  "select * from process_open_sockets where pid = 1",
])

其中有几个列名需要说明一下:

  • fd,表示文件描述符
  • socket,进行网络通讯时,socket通信对应的inode number
  • family,表示是IPv4/IPv6,最后的结果是以数字的方式展示
  • protocol,表示是TCP/UDP。

我们进行一个简单的反弹shell的操作,然后使用查询process_open_sockets表的信息。

osquery> select pos.*,p.cwd,p.cmdline from process_open_sockets pos left join processes p where pos.family=2 and pos.pid=p.pid and net_namespace<>0;
+-------+----+----------+--------+----------+---------------+----------------+------------+-------------+------+-------------+---------------+-----------------+-----------+
| pid   | fd | socket   | family | protocol | local_address | remote_address | local_port | remote_port | path | state       | net_namespace | cwd             | cmdline   |
+-------+----+----------+--------+----------+---------------+----------------+------------+-------------+------+-------------+---------------+-----------------+-----------+
| 37272 | 15 | 52319299 | 2      | 6        | 192.168.2.142 | 172.22.0.176   | 43522      | 9091        |      | ESTABLISHED | 4026531956    | /home/xingjun   | osqueryi  |
| 91155 | 2  | 56651533 | 2      | 6        | 192.168.2.142 | 192.168.2.150  | 53486      | 8888        |      | ESTABLISHED | 4026531956    | /proc/79036/net | /bin/bash |
+-------+----+----------+--------+----------+---------------+----------------+------------+-------------+------+-------------+---------------+-----------------+-----------+

process_open_sockets表的实现是位于osquery/tables/networking/linux/process_open_sockets.cpp中。

分析

process_open_sockets的实现全部是在QueryData genOpenSockets(QueryContext &context)一个方法中。

官方给出的分析步骤是:

Data for this table is fetched from 3 different sources and correlated.

1.Collect all sockets associated with each pid by going through all files under /proc/<pid>/fd and search for links of the type socket:[<inode>]. Extract the inode and fd (filename) and index it by inode number. The inode can then be used to correlate pid and fd with the socket information collected on step 3. The map generated in this step will only contain sockets associated with pids in the list, so it will also be used to filter the sockets later if pid_filter is set.

2.Collect the inode for the network namespace associated with each pid. Every time a new namespace is found execute step 3 to get socket basic information.

3.Collect basic socket information for all sockets under a specifc network namespace. This is done by reading through files under /proc/<pid>/net for the first pid we find in a certain namespace. Notice this will collect information for all sockets on the namespace not only for sockets associated with the specific pid, therefore only needs to be run once. From this step we collect the inodes of each of the sockets, and will use that to correlate the socket information with the information collect on steps 1 and 2.

其实大致步骤就是:

  1. 收集进程所对应的fd信息,尤其是socketinode信息;
  2. 收集进程的namespaceinode信息;
  3. 读取/proc/<pid>/net中的信息,与第一步中的socketinode信息进行比对,找出pid所对应的网络连接信息。

为了方便说明,我对整个函数的代码进行切割,分步说明。

获取pid信息

std::set <std::string> pids;
if (context.constraints["pid"].exists(EQUALS)) {
    pids = context.constraints["pid"].getAll(EQUALS);
}

bool pid_filter = !(pids.empty() ||
                    std::find(pids.begin(), pids.end(), "-1") != pids.end());

if (!pid_filter) {
    pids.clear();
    status = osquery::procProcesses(pids);
    if (!status.ok()) {
        VLOG(1) << "Failed to acquire pid list: " << status.what();
        return results;
    }
}
  • 前面的context.constraints["pid"].exists(EQUALS)pid_filter为了判断在SQL语句中是否存在where子句以此拿到选择的pid
  • 调用status = osquery::procProcesses(pids);拿到对应的PID信息。

跟踪进入到osquery/filesystem/linux/proc.cpp:procProcesses(std::set<std::string>& processes):

Status procProcesses(std::set<std::string>& processes) {
  auto callback = [](const std::string& pid,
                     std::set<std::string>& _processes) -> bool {
    _processes.insert(pid);
    return true;
  };

  return procEnumerateProcesses<decltype(processes)>(processes, callback);
}

继续跟踪进入到osquery/filesystem/linux/proc.h:procEnumerateProcesses(UserData& user_data,bool (*callback)(const std::string&, UserData&))

const std::string kLinuxProcPath = "/proc";
.....
template<typename UserData>
Status procEnumerateProcesses(UserData &user_data,bool (*callback)(const std::string &, UserData &)) {
    boost::filesystem::directory_iterator it(kLinuxProcPath), end;

    try {
        for (; it != end; ++it) {
            if (!boost::filesystem::is_directory(it->status())) {
                continue;
            }

            // See #792: std::regex is incomplete until GCC 4.9
            const auto &pid = it->path().leaf().string();
            if (std::atoll(pid.data()) <= 0) {
                continue;
            }

            bool ret = callback(pid, user_data);
            if (ret == false) {
                break;
            }
        }
    } catch (const boost::filesystem::filesystem_error &e) {
        VLOG(1) << "Exception iterating Linux processes: " << e.what();
        return Status(1, e.what());
    }

    return Status(0);
}
  • boost::filesystem::directory_iterator it(kLinuxProcPath), end;遍历/proc目录下面所有的文件,
  • const auto &pid = it->path().leaf().string();..; bool ret = callback(pid, user_data);,通过it->path().leaf().string()判断是否为数字,之后调用bool ret = callback(pid, user_data);
  • callback方法_processes.insert(pid);return true;将查询到的pid全部记录到user_data中。

以一个反弹shell的例子为例,使用osqueryi查询到的信息如下:

osquery> select * from process_open_sockets where pid=14960; 
+-------+----+--------+--------+----------+---------------+----------------+------------+-------------+------+-------------+---------------+
| pid   | fd | socket | family | protocol | local_address | remote_address | local_port | remote_port | path | state       | net_namespace |
+-------+----+--------+--------+----------+---------------+----------------+------------+-------------+------+-------------+---------------+
| 14960 | 2  | 307410 | 2      | 6        | 192.168.2.156 | 192.168.2.145  | 51118      | 8888        |      | ESTABLISHED | 4026531956    |
+-------+----+--------+--------+----------+---------------+----------------+------------+-------------+------+-------------+---------------+

获取进程对应的pid和fd信息

/* Use a set to record the namespaces already processed */
std::set <ino_t> netns_list;
SocketInodeToProcessInfoMap inode_proc_map;
SocketInfoList socket_list;
for (const auto &pid : pids) {
    /* Step 1 */
    status = procGetSocketInodeToProcessInfoMap(pid, inode_proc_map);
    if (!status.ok()) {
        VLOG(1) << "Results for process_open_sockets might be incomplete. Failed "
                    "to acquire socket inode to process map for pid "
                << pid << ": " << status.what();
    }

在拿到所有的需要查询的pid信息之后,调用status = procGetSocketInodeToProcessInfoMap(pid, inode_proc_map);,顾名思义就是用于获取进程所对应的socket inode编号。进入到osquery/filesystem/linux/proc.cpp:procGetSocketInodeToProcessInfoMap()中:

Status procGetSocketInodeToProcessInfoMap(const std::string &pid,SocketInodeToProcessInfoMap &result) {
    auto callback = [](const std::string &_pid,
                        const std::string &fd,
                        const std::string &link,
                        SocketInodeToProcessInfoMap &_result) -> bool {
        /* We only care about sockets. But there will be other descriptors. */
        if (link.find("socket:[") != 0) {
            return true;
        }

        std::string inode = link.substr(8, link.size() - 9);
        _result[inode] = {_pid, fd};
        return true;
    };

    return procEnumerateProcessDescriptors<decltype(result)>(
            pid, result, callback);
}

其中的auto callback定义的是一个回调函数,进入到procEnumerateProcessDescriptors()中分析:

const std::string kLinuxProcPath = "/proc";
....
template<typename UserData>
Status procEnumerateProcessDescriptors(const std::string &pid,
                                        UserData &user_data,
                                        bool (*callback)(const std::string &pid,
                                                        const std::string &fd,
                                                        const std::string &link,
                                                        UserData &user_data)) {
    std::string descriptors_path = kLinuxProcPath + "/" + pid + "/fd";

    try {
        boost::filesystem::directory_iterator it(descriptors_path), end;

        for (; it != end; ++it) {
            auto fd = it->path().leaf().string();

            std::string link;
            Status status = procReadDescriptor(pid, fd, link);
            if (!status.ok()) {
                VLOG(1) << "Failed to read the link for file descriptor " << fd
                        << " of pid " << pid << ". Data might be incomplete.";
            }

            bool ret = callback(pid, fd, link, user_data);
            if (ret == false) {
                break;
            }
        }
    } catch (boost::filesystem::filesystem_error &e) {
        VLOG(1) << "Exception iterating process file descriptors: " << e.what();
        return Status(1, e.what());
    }

    return Status(0);
}

这个代码写得十分清晰。

1.遍历/proc/pid/fd,拿到所有的文件描述符。在本例中即为/proc/14960/fd

1.jpg

2.回调bool ret = callback(pid, fd, link, user_data);,即之前在procGetSocketInodeToProcessInfoMap中定义的:

auto callback = [](const std::string &_pid,
                    const std::string &fd,
                    const std::string &link,
                    SocketInodeToProcessInfoMap &_result) -> bool {
    /* We only care about sockets. But there will be other descriptors. */
    if (link.find("socket:[") != 0) {
        return true;
    }

    std::string inode = link.substr(8, link.size() - 9);
    _result[inode] = {_pid, fd};
    return true;
};

代码也十分地简单,拿到fd所对应的link,检查是否存在socket:[,如果存在获取对应的inode。由于查询的是process_open_sockets,所以我们仅仅只关心存在socket的link,在本例中就是307410。最终在SocketInodeToProcessInfoMap中的结构就是_result[inode] = {_pid, fd};。以inode作为key,包含了pidfd的信息。

获取进程对应的ns信息

在上一步status = procGetSocketInodeToProcessInfoMap(pid, inode_proc_map);执行完毕之后,得到_result[inode] = {_pid, fd};。将inodepidfd进行了关联。接下里就是解析进程对应的ns信息。

ino_t ns;
ProcessNamespaceList namespaces;
status = procGetProcessNamespaces(pid, namespaces, {"net"});
if (status.ok()) {
    ns = namespaces["net"];
} else {
    /* If namespaces are not available we allways set ns to 0 and step 3 will
        * run once for the first pid in the list.
        */
    ns = 0;
    VLOG(1) << "Results for the process_open_sockets might be incomplete."
                "Failed to acquire network namespace information for process "
                "with pid "
            << pid << ": " << status.what();
}
跟踪进入到`status = procGetProcessNamespaces(pid, namespaces, {"net"});`,进入到`osquery/filesystem/linux/proc.cpp:procGetProcessNamespaces()`
const std::string kLinuxProcPath = "/proc";
...
Status procGetProcessNamespaces(const std::string &process_id,ProcessNamespaceList &namespace_list,std::vector <std::string> namespaces) {
    namespace_list.clear();
    if (namespaces.empty()) {
        namespaces = kUserNamespaceList;
    }
    auto process_namespace_root = kLinuxProcPath + "/" + process_id + "/ns";
    for (const auto &namespace_name : namespaces) {
        ino_t namespace_inode;
        auto status = procGetNamespaceInode(namespace_inode, namespace_name, process_namespace_root);
        if (!status.ok()) {
            continue;
        }
        namespace_list[namespace_name] = namespace_inode;
    }
    return Status(0, "OK");
}

遍历const auto &namespace_name : namespaces,之后进入到process_namespace_root中,调用procGetNamespaceInode(namespace_inode, namespace_name, process_namespace_root);进行查询。在本例中namespaces{"net"},process_namespace_root/proc/14960/ns

分析procGetNamespaceInode(namespace_inode, namespace_name, process_namespace_root):

Status procGetNamespaceInode(ino_t &inode,const std::string &namespace_name,const std::string &process_namespace_root) {
    inode = 0;
    auto path = process_namespace_root + "/" + namespace_name;
    char link_destination[PATH_MAX] = {};
    auto link_dest_length = readlink(path.data(), link_destination, PATH_MAX - 1);
    if (link_dest_length < 0) {
        return Status(1, "Failed to retrieve the inode for namespace " + path);
    }

    // The link destination must be in the following form: namespace:[inode]
    if (std::strncmp(link_destination,
                        namespace_name.data(),
                        namespace_name.size()) != 0 ||
        std::strncmp(link_destination + namespace_name.size(), ":[", 2) != 0) {
        return Status(1, "Invalid descriptor for namespace " + path);
    }

    // Parse the inode part of the string; strtoull should return us a pointer
    // to the closing square bracket
    const char *inode_string_ptr = link_destination + namespace_name.size() + 2;
    char *square_bracket_ptr = nullptr;

    inode = static_cast<ino_t>(
            std::strtoull(inode_string_ptr, &square_bracket_ptr, 10));
    if (inode == 0 || square_bracket_ptr == nullptr ||
        *square_bracket_ptr != ']') {
        return Status(1, "Invalid inode value in descriptor for namespace " + path);
    }

    return Status(0, "OK");
}

根据procGetProcessNamespaces()中定义的相关变量,得到path是/proc/pid/ns/net,在本例中是/proc/14960/ns/net。通过inode = static_cast<ino_t>(std::strtoull(inode_string_ptr, &square_bracket_ptr, 10));,解析/proc/pid/ns/net所对应的inode。在本例中:

2.jpg

所以取到的inode4026531956。之后在procGetProcessNamespaces()中执行namespace_list[namespace_name] = namespace_inode;,所以namespace_list['net']=4026531956。最终ns = namespaces["net"];,所以得到的ns=4026531956

解析进程的net信息

// Linux proc protocol define to net stats file name.
const std::map<int, std::string> kLinuxProtocolNames = {
        {IPPROTO_ICMP,    "icmp"},
        {IPPROTO_TCP,     "tcp"},
        {IPPROTO_UDP,     "udp"},
        {IPPROTO_UDPLITE, "udplite"},
        {IPPROTO_RAW,     "raw"},
};
...
if (netns_list.count(ns) == 0) {
    netns_list.insert(ns);

    /* Step 3 */
    for (const auto &pair : kLinuxProtocolNames) {
        status = procGetSocketList(AF_INET, pair.first, ns, pid, socket_list);
        if (!status.ok()) {
            VLOG(1)
                    << "Results for process_open_sockets might be incomplete. Failed "
                        "to acquire basic socket information for AF_INET "
                    << pair.second << ": " << status.what();
        }

        status = procGetSocketList(AF_INET6, pair.first, ns, pid, socket_list);
        if (!status.ok()) {
            VLOG(1)
                    << "Results for process_open_sockets might be incomplete. Failed "
                        "to acquire basic socket information for AF_INET6 "
                    << pair.second << ": " << status.what();
        }
    }
    status = procGetSocketList(AF_UNIX, IPPROTO_IP, ns, pid, socket_list);
    if (!status.ok()) {
        VLOG(1)
                << "Results for process_open_sockets might be incomplete. Failed "
                    "to acquire basic socket information for AF_UNIX: "
                << status.what();
    }
}

对于icmp/tcp/udp/udplite/raw会调用status = procGetSocketList(AF_INET|AF_INET6|AF_UNIX, pair.first, ns, pid, socket_list);。我们这里仅仅以procGetSocketList(AF_INET, pair.first, ns, pid, socket_list);进行说明(其中的ns就是4026531956)。

Status procGetSocketList(int family, int protocol,ino_t net_ns,const std::string &pid, SocketInfoList &result) {
    std::string path = kLinuxProcPath + "/" + pid + "/net/";

    switch (family) {
        case AF_INET:
            if (kLinuxProtocolNames.count(protocol) == 0) {
                return Status(1,"Invalid family " + std::to_string(protocol) +" for AF_INET familiy");
            } else {
                path += kLinuxProtocolNames.at(protocol);
            }
            break;

        case AF_INET6:
            if (kLinuxProtocolNames.count(protocol) == 0) {
                return Status(1,"Invalid protocol " + std::to_string(protocol) +" for AF_INET6 familiy");
            } else {
                path += kLinuxProtocolNames.at(protocol) + "6";
            }
            break;

        case AF_UNIX:
            if (protocol != IPPROTO_IP) {
                return Status(1,
                                "Invalid protocol " + std::to_string(protocol) +
                                " for AF_UNIX familiy");
            } else {
                path += "unix";
            }

            break;

        default:
            return Status(1, "Invalid family " + std::to_string(family));
    }

    std::string content;
    if (!osquery::readFile(path, content).ok()) {
        return Status(1, "Could not open socket information from " + path);
    }

    Status status(0);
    switch (family) {
        case AF_INET:
        case AF_INET6:
            status = procGetSocketListInet(family, protocol, net_ns, path, content, result);
            break;

        case AF_UNIX:
            status = procGetSocketListUnix(net_ns, path, content, result);
            break;
    }

    return status;
}

由于我们的传参是family=AF_INET,protocol=tcp,net_ns=4026531956,pid=14960。执行流程如下:

1.path += kLinuxProtocolNames.at(protocol);,得到path是/proc/14960/net/tcp

2.osquery::readFile(path, content).ok(),读取文件内容,即/proc/14960/net/tcp所对应的文件内容。在本例中是:

sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
0: 00000000:1538 00000000:0000 0A 00000000:00000000 00:00000000 00000000    26        0 26488 1 ffff912c69c21740 100 0 0 10 0
1: 0100007F:0019 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 28721 1 ffff912c69c23640 100 0 0 10 0
2: 00000000:01BB 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 27739 1 ffff912c69c21f00 100 0 0 10 0
3: 0100007F:18EB 00000000:0000 0A 00000000:00000000 00:00000000 00000000   988        0 25611 1 ffff912c69c207c0 100 0 0 10 0
4: 00000000:0050 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 27737 1 ffff912c69c226c0 100 0 0 10 0
5: 017AA8C0:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 29031 1 ffff912c69c23e00 100 0 0 10 0
6: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 25754 1 ffff912c69c20f80 100 0 0 10 0
7: 0100007F:0277 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 25590 1 ffff912c69c20000 100 0 0 10 0
8: 9C02A8C0:C7AE 9102A8C0:22B8 01 00000000:00000000 00:00000000 00000000  1000

3.执行procGetSocketListInet(family, protocol, net_ns, path, content, result);

分析

static Status procGetSocketListInet(int family,int protocol,ino_t net_ns,const std::string &path,const std::string &content,SocketInfoList &result) {
    // The system's socket information is tokenized by line.
    bool header = true;
    for (const auto &line : osquery::split(content, "\n")) {
        if (header) {
            if (line.find("sl") != 0 && line.find("sk") != 0) {
                return Status(1, std::string("Invalid file header for ") + path);
            }
            header = false;
            continue;
        }

        // The socket information is tokenized by spaces, each a field.
        auto fields = osquery::split(line, " ");
        if (fields.size() < 10) {
            VLOG(1) << "Invalid socket descriptor found: '" << line
                    << "'. Skipping this entry";
            continue;
        }

        // Two of the fields are the local/remote address/port pairs.
        auto locals = osquery::split(fields[1], ":");
        auto remotes = osquery::split(fields[2], ":");

        if (locals.size() != 2 || remotes.size() != 2) {
            VLOG(1) << "Invalid socket descriptor found: '" << line
                    << "'. Skipping this entry";
            continue;
        }

        SocketInfo socket_info = {};
        socket_info.socket = fields[9];
        socket_info.net_ns = net_ns;
        socket_info.family = family;
        socket_info.protocol = protocol;
        socket_info.local_address = procDecodeAddressFromHex(locals[0], family);
        socket_info.local_port = procDecodePortFromHex(locals[1]);
        socket_info.remote_address = procDecodeAddressFromHex(remotes[0], family);
        socket_info.remote_port = procDecodePortFromHex(remotes[1]);

        if (protocol == IPPROTO_TCP) {
            char *null_terminator_ptr = nullptr;
            auto integer_socket_state =
                    std::strtoull(fields[3].data(), &null_terminator_ptr, 16);
            if (integer_socket_state == 0 ||
                integer_socket_state >= tcp_states.size() ||
                null_terminator_ptr == nullptr || *null_terminator_ptr != 0) {
                socket_info.state = "UNKNOWN";
            } else {
                socket_info.state = tcp_states[integer_socket_state];
            }
        }

        result.push_back(std::move(socket_info));
    }

    return Status(0);
}

整个执行流程如下:

1.const auto &line : osquery::split(content, "\n");.. auto fields = osquery::split(line, " ");解析文件,读取每一行的内容。对每一行采用空格分割;

2.解析信息

SocketInfo socket_info = {};
socket_info.socket = fields[9];
socket_info.net_ns = net_ns;
socket_info.family = family;
socket_info.protocol = protocol;
socket_info.local_address = procDecodeAddressFromHex(locals[0], family);
socket_info.local_port = procDecodePortFromHex(locals[1]);
socket_info.remote_address = procDecodeAddressFromHex(remotes[0], family);
socket_info.remote_port = procDecodePortFromHex(remotes[1]);

解析/proc/14960/net/tcp文件中的每一行,分别填充至socket_info结构中。但是在/proc/14960/net/tcp并不是所有的信息都是我们需要的,我们还需要对信息进行过滤。可以看到最后一条的inode307410才是我们需要的。

获取进程连接信息

将解析完毕/proc/14960/net/tcp获取socket_info之后,继续执行genOpenSockets()中的代码。

    auto proc_it = inode_proc_map.find(info.socket);
    if (proc_it != inode_proc_map.end()) {
        r["pid"] = proc_it->second.pid;
        r["fd"] = proc_it->second.fd;
    } else if (!pid_filter) {
        r["pid"] = "-1";
        r["fd"] = "-1";
    } else {
        /* If we're filtering by pid we only care about sockets associated with
            * pids on the list.*/
        continue;
    }

    r["socket"] = info.socket;
    r["family"] = std::to_string(info.family);
    r["protocol"] = std::to_string(info.protocol);
    r["local_address"] = info.local_address;
    r["local_port"] = std::to_string(info.local_port);
    r["remote_address"] = info.remote_address;
    r["remote_port"] = std::to_string(info.remote_port);
    r["path"] = info.unix_socket_path;
    r["state"] = info.state;
    r["net_namespace"] = std::to_string(info.net_ns);

    results.push_back(std::move(r));
}

其中关键代码是:

auto proc_it = inode_proc_map.find(info.socket);
if (proc_it != inode_proc_map.end()) {

通过遍历socket_list,判断在第一步保存在inode_proc_map中的inode信息与info中的inode信息是否一致,如果一致,说明就是我们需要的那个进程的网络连接的信息。最终保存我们查询到的信息results.push_back(std::move(r));
到这里,我们就查询到了进程的所有的网络连接的信息。最终通过osquery展现。

osquery> select * from process_open_sockets where pid=14960; 
+-------+----+--------+--------+----------+---------------+----------------+------------+-------------+------+-------------+---------------+
| pid   | fd | socket | family | protocol | local_address | remote_address | local_port | remote_port | path | state       | net_namespace |
+-------+----+--------+--------+----------+---------------+----------------+------------+-------------+------+-------------+---------------+
| 14960 | 2  | 307410 | 2      | 6        | 192.168.2.156 | 192.168.2.145  | 51118      | 8888        |      | ESTABLISHED | 4026531956    |
+-------+----+--------+--------+----------+---------------+----------------+------------+-------------+------+-------------+---------------+

以上就是整个osquery执行process_open_sockets表查询的整个流程。

扩展

Linux一些皆文件的特性,使得我们能够通过读取Linux下某些文件信息获取系统/进程所有的信息。在前面我们仅仅是从osquery的角度来分析的。本节主要是对Linux中的与网络有关、进程相关的信息进行说明。

/proc/net/tcp/proc/net/udp中保存了当前系统中所有的进程信息,与/proc/pid/net/tcp或者是/proc/pid/net/udp中保存的信息完全相同。

/proc/net/tcp信息如下:

sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
0: 00000000:1538 00000000:0000 0A 00000000:00000000 00:00000000 00000000    26        0 26488 1 ffff912c69c21740 100 0 0 10 0
1: 0100007F:0019 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 28721 1 ffff912c69c23640 100 0 0 10 0
2: 00000000:01BB 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 27739 1 ffff912c69c21f00 100 0 0 10 0
3: 00000000:1F40 00000000:0000 0A 00000000:00000000 00:00000000 00000000  1000        0 471681 1 ffff912c37488f80 100 0 0 10 0
4: 0100007F:18EB 00000000:0000 0A 00000000:00000000 00:00000000 00000000   988        0 25611 1 ffff912c69c207c0 100 0 0 10 0
5: 00000000:0050 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 27737 1 ffff912c69c226c0 100 0 0 10 0
6: 017AA8C0:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 29031 1 ffff912c69c23e00 100 0 0 10 0
7: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 25754 1 ffff912c69c20f80 100 0 0 10 0
8: 0100007F:0277 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 25590 1 ffff912c69c20000 100 0 0 10 0
9: 9C02A8C0:C7AE 9102A8C0:22B8 01 00000000:00000000 00:00000000 00000000  1000        0 307410 1 ffff912c374887c0 20 0 0 10 -1

/proc/14960/net/tcp信息如下:

sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
0: 00000000:1538 00000000:0000 0A 00000000:00000000 00:00000000 00000000    26        0 26488 1 ffff912c69c21740 100 0 0 10 0
1: 0100007F:0019 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 28721 1 ffff912c69c23640 100 0 0 10 0
2: 00000000:01BB 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 27739 1 ffff912c69c21f00 100 0 0 10 0
3: 0100007F:18EB 00000000:0000 0A 00000000:00000000 00:00000000 00000000   988        0 25611 1 ffff912c69c207c0 100 0 0 10 0
4: 00000000:0050 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 27737 1 ffff912c69c226c0 100 0 0 10 0
5: 017AA8C0:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 29031 1 ffff912c69c23e00 100 0 0 10 0
6: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 25754 1 ffff912c69c20f80 100 0 0 10 0
7: 0100007F:0277 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 25590 1 ffff912c69c20000 100 0 0 10 0
8: 9C02A8C0:C7AE 9102A8C0:22B8 01 00000000:00000000 00:00000000 00000000  1000        0 307410 1 ffff912c374887c0 20 0 0 10 -1

我们每一列的含义都是固定的,我们以最终一列9C02A8C0:C7AE 9102A8C0:22B8 01 00000000:00000000 00:00000000 00000000 1000 0 307410 1 ffff912c374887c0 20 0 0 10 -1为例进行说明。

1.local_address,本地通讯端口和IP,本例是9C02A8C0:C7AE9C02A8C0,是本地IP。9C02A8C0是十六进制,转换为十进制是2617419968,将其转换为IP地址则是156.2.168.192,倒装一下得到192.168.2.156C7AE转化为十进制是51118。所以当进行网络通信时,得到本地IP是192.168.2.156,端口是51118

2.rem_address,远程服务器通信端口和IP,本例是9102A8C0:22B89102A8C0是远程IP。分析方法和local_address相同,得到远程IP是192.168.2.145,端口是8888

3.st,socket的状态,本例是01st的不同的值表示不同的含义。

  • 01: ESTABLISHED,
  • 02: SYN_SENT
  • 03: SYN_RECV
  • 04: FIN_WAIT1
  • 05: FIN_WAIT2
  • 06: TIME_WAIT
  • 07: CLOSE
  • 08: CLOSE_WAIT
  • 09: LAST_ACK
  • 0A: LISTEN
  • 0B: CLOSING

所以在本例中01则说明是ESTABLISHED状态。

4.tx_queue, 表示发送队列中的数据长度,本例是00000000

5.rx_queue, 如果状态是ESTABLISHED,表示接受队列中数据长度;如果是LISTEN,表示已完成连接队列的长度;

6.tr,定时器类型。为0,表示没有启动计时器;为1,表示重传定时器;为2,表示连接定时器;为3,表示TIME_WAIT定时器;为4,表示持续定时器;

7.tm->when,超时时间。

8.retrnsmt,超时重传次数

9.uid,用户id

10.timeout,持续定时器或保洁定时器周期性发送出去但未被确认的TCP段数目,在收到ACK之后清零

11.inode,socket连接对应的inode

12.1,没有显示header,表示的是socket的引用数目

13.ffff912c374887c0,没有显示header,表示sock结构对应的地址

14.20,没有显示header,表示RTO,单位是clock_t

15.0,用来计算延时确认的估值

16.0,快速确认数和是否启用标志位的或元算结果

17.10,当前拥塞窗口大小

18.-1,如果慢启动阈值大于等于0x7fffffff显示-1,否则表示慢启动阈值

proc_net_tcp_decode这篇文章对每个字段也进行了详细地说明。

通过查看某个具体的pidfd信息,检查是否存在以socket:开头的文件描述符,如果存在则说明存在网络通信。

3.jpg

在得到了socket所对应的inode之后,就可以在/proc/net/tcp中查询对应的socket的信息,比如远程服务器的IP和端口信息。这样通过socketinode就可以关联进程信息和它的网络信息。

总结

论读源代码的重要性

以上

大力出奇迹:Web架构中的安全问题一例

前言

在一次对线上业务的测试中,遇到过一个奇怪的问题,经排查和LVS以及后台应用服务的同步有关,现在分享如下;并对web架构的基础知识和个人经验认为可能存在的问题做简单的总结。

现象

  1. 爆破接口本来是做了防护的,即当某IP的请次数超过一定的阀值后返回403(正常请求返回的是200),但是大量的多线程请求中出现了某些请求仍然正常的情况。如图:

burp.png

  1. 在某次对另一个业务的测试中,也发现了类似的问题。某登录接口,多次尝试后开始要求图形验证码确认,但当用户多次点击按钮请求,图形验证码要求却消失了。

原因

经过运维的排查,发现根本原因是后端多台服务器配置不一致导致的,比如有三台服务器的代码是最新的,有防护策略,而有一台服务器的代码没有得到更新,没有防护策略,当多次请求的时候,LVS将流量指向了没有启用防护策略的服务器,响应包也就没有要求图形验证或响应正常,从而导致了多个请求中存在了无需验证的数据包。

测试方法和利用

多线程、高并发请求;这些大量异常包中的正常请求也是有可能被利用的,比如,如果LVS是轮询算法,即每N次就有一次可利用的请求。

总结

现在的web应用早已不是单台服务器的时代了,往往都有一个庞大的web架构来支撑一个应用。个人学习了一下相关基础知识,并根据经验罗列了一下这些架构中可能存在的问题。

习惯了通过思维导图来记录知识,高清大图请点击或者右键查看:

xmind.png

Xmind源文件请访问Github获取。

互联网企业安全高级指南读书笔记

前言

春节前花了几天时间,终于把这本书完整读完了。受益匪浅!

这是市面上第一本从总览的视角陈述甲方企业安全建设思路与框架,描绘企业内部信息安全全貌的书。

除了“战略”层面的全局观,这本书还难能可贵的深入了一些技术细节,在“战术”层面也不乏很多干货。

为了帮助记忆和理解,我基本上每章都用思维导图的方式整理了笔记。

这些笔记并非对全书的完整总结,亦非斗胆点评,仅作为个人理解和梳理思路的笔记之用。

第三章 甲方安全建设方法论

第三章.png

第四章 业界的模糊地带

第四章.png

第五章 防御架构原则

第五章.png

第六章 基础设施安全

第六章.png

第七章 网络安全

第七章.png

第八章 入侵感知体系

第八章.png

第九章 漏洞扫描

第九章.png

总结

总得来说,互联网企业和传统行业企业在安全建设的思路上,殊途同归。

不同点

  • 扩展性

互联网企业的业态具有大流量、高实时性、海量用户、海量数据的显著特征。由于流量太大,所以“两个海量”的特征与传统企业非常不一样。同时,互联网企业的线上业务就是钱,这样就决定了高实时性是必保的点。传统企业的线上业务即便是挂了,在一定时间内也不会直接影响生产力。

为了应对一大一高两个海量,传统安全企业的解决方案存在先天不足:无法无缝横向扩展。这就导致了互联网企业更多的选择自研防护手段。

互联网企业对安全防护手段的要求是,低维护成本+高扩展性。而传统企业呢,更看重的是易配置+防护全面。

  • 自研能力

这一点非常容易理解。互联网企业拥有足够的薪资吸引高端人才,所以才能支撑自研的需求。而传统企业除了保护线上业务外,还需要应对合规、内部防泄密等安全外延业务诉求。自身也不具备自研的能力。

相同点

  • 分层防御+威胁感知

无论是线上业务防攻击,还是内部治理防泄密,都必须依赖分层设计的多重防御措施交互实现立体化、深层次的防御能力。应对瞬息万变的攻击特征,必须具备第一时间感知威胁发生的能力。所以,无论是威胁情报,还是大数据分析,这些技术在不同业态的甲方企业内都会有持续的生命力和价值点。综上,虽然业态不同,但核心思想还是相通的。

另外,作者赵老师在书中提到,传统企业迫于提高生产力、提高效率的压力,业态向互联网转化的速度会越来越快。所以,互联网企业在线上业务安全防御方面的经验,领先传统企业十年,此言不虚。安全的本质始终没有变,就看在不同环境下怎么玩的踏实,怎么玩出精彩。

与君共勉。

企业常见服务漏洞检测&修复整理

前言

12月份要要给公司同学做安全技术分享,有一块是讲常见服务的漏洞,网上的漏洞检测和修复方案写都比较散,在这里一起做一个整合,整理部分常见服务最近的漏洞和使用上的安全隐患方便有需要的朋友查看。如文章有笔误的地方请与我联系WeChat:atiger77

目录

1.内核级别漏洞

Dirty COW

2.应用程序漏洞

Nginx
Tomcat
Glassfish
Gitlab
Mysql
Struts2
ImageMagick
...

3.应用安全隐患

SSH
Redis
Jenkins
Zookeeper
Zabbix 
Elasticsearch
Docker
...

4.总结

漏洞检测&修复方法

1.内核级别漏洞

Dirty COW脏牛漏洞,Linux 内核内存子系统的 COW 机制在处理内存写入时存在竞争,导致只读内存页可能被篡改。

影响范围:Linux kernel >= 2.6.22

漏洞影响:低权限用户可以利用该漏洞写入对自身只读的内存页(包括可写文件系统上对该用户只读的文件)并提权至 root

PoC参考:

漏洞详情&修复参考:

这个漏洞对于使用linux系统的公司来说是一定要修复的,拿web服务举例,我们使用一个低权限用户开放web服务当web被攻击者挂了shell就可以使用exp直接提权到root用户。目前某些云厂商已经在基础镜像中修复了这个问题但是对于之前已创建的主机需要手动修复,具体修复方案可以参考长亭的文章。

2.应用程序漏洞

Nginx

Nginx是企业中出现频率最高的服务之一,常用于web或者反代功能。11月15日,国外安全研究员Dawid Golunski公开了一个新的Nginx漏洞(CVE-2016-1247),能够影响基于Debian系列的发行版。

影响范围:

  • Debian: Nginx1.6.2-5+deb8u3
  • Ubuntu 16.04: Nginx1.10.0-0ubuntu0.16.04.3
  • Ubuntu 14.04: Nginx1.4.6-1ubuntu3.6
  • Ubuntu 16.10: Nginx1.10.1-0ubuntu1.1

漏洞详情&修复参考:

这个漏洞需要获取主机操作权限,攻击者可通过软链接任意文件来替换日志文件,从而实现提权以获取服务器的root权限。对于企业来说如果nginx部署在Ubuntu或者Debian上需要查看发行版本是否存在问题即使打上补丁即可,对于RedHat类的发行版则不需要任何修复。

Tomcat

Tomcat于10月1日曝出本地提权漏洞CVE-2016-1240。仅需Tomcat用户低权限,攻击者就能利用该漏洞获取到系统的ROOT权限。

影响范围: Tomcat 8 <= 8.0.36-2 Tomcat 7 <= 7.0.70-2 Tomcat 6 <= 6.0.45+dfsg-1~deb8u1

受影响的系统包括Debian、Ubuntu,其他使用相应deb包的系统也可能受到影响

漏洞详情&修复参考:

CVE-2016-4438这一漏洞其问题出在Tomcat的deb包中,使 deb包安装的Tomcat程序会自动为管理员安装一个启动脚本:/etc/init.d/tocat* 利用该脚本,可导致攻击者通过低权限的Tomcat用户获得系统root权限。

实现这个漏洞必须要重启tomcat服务,作为企业做好服务器登录的权限控制,升级有风险的服务可避免问题。

当然在企业中存在不少部署问题而导致了Tomcat存在安全隐患,运维部署完环境后交付给开发同学,如果没有删除Tomcat默认的文件夹就开放到了公网,攻击者可以通过部署WAR包的方式来获取机器权限。

Glassfish

Glassfish是用于构建 Java EE 5应用服务器的开源开发项目的名称。它基于 Sun Microsystems 提供的 Sun Java System Application Server PE 9 的源代码以及 Oracle 贡献的 TopLink 持久性代码。低版本存在任何文件读取漏洞。

影响范围:Glassfish4.0至4.1

修复参考:升级至4.11或以上版本

PoC参考:

http://1.2.3.4:4848/theme/META-INF/%c0.%c0./%c0.%c0./%c0.%c0./%c0.%c0./%c0.%c0./domains/
domain1/config/admin-keyfile

因为公司有用到Glassfish服务,当时在乌云上看到PoC也测试了下4.0的确存在任何文件读取问题,修复方法也是升级到4.11及以上版本。

Gitlab

Gitlab是一个用于仓库管理系统的开源项目。含义使用Git作为代码管理工具,越来越多的公司从SVN逐步移到Gitlab上来,由于存放着公司代码,数据安全也变得格外重要。

影响范围:

  • 任意文件读取漏洞(CVE-2016-9086): GitLab CE/EEversions 8.9, 8.10, 8.11, 8.12,
    and 8.13
  • 任意用户authentication_token泄露漏洞: Gitlab CE/EE versions 8.10.3-8.10.5

漏洞详情&修复参考:

http://blog.knownsec.com/2016/11/gitlab-file-read-vulnerability-cve-2016-9086-and-access-all-user-authentication-token/

互联网上有不少公司的代码仓库公网可直接访问,有些是历史原因有些是没有考虑到安全隐患,对于已经部署在公网的情况,可以让Gitlab强制开启二次认证防止暴力破解这里建议使用Google的身份验证,修改默认访问端口,做好acl只允许指定IP进行访问。

Mysql

Mysql是常见的关系型数据库之一,翻了下最新的漏洞情况有CVE-2016-6662和一个Mysql代码执行漏洞。由于这两个漏洞实现均需要获取到服务器权限,这里就不展开介绍漏洞有兴趣的可以看下相关文章,主要讲一下Mysql安全加固。

漏洞详情&修复参考:

在互联网企业中Mysql是很常见的服务,我这边提几点Mysql的安全加固,首先对于某些高级别的后台比如运营,用户等能涉及到用户信息的可以做蜜罐表。在项目申请资源的时候就要做好权限的划分,我们是运维同学保留最高权限,给开发一个只读用户和一个开发权限的用户进行使用,密码一律32位,同时指定机器登录数据库,删除默认数据库和数据库用户。

找了一篇还不错的加固文章提供参考:http://www.it165.net/database/html/201210/3132.html

Struts2

Struts2是一个优雅的,可扩展的框架,用于创建企业准备的Java Web应用程序。出现的漏洞也着实的多每爆一个各大漏洞平台上就会被刷屏。

漏洞详情&修复参考:

在线检测平台: http://0day.websaas.com.cn/

记得有一段时间Struts2的漏洞连续被爆出,自动化的工具也越来越多S2-032,S2-033,S2-037,乌云首页上都是Struts2的漏洞,有国企行业的有证券公司的使用者都分分中招,如果有使用的话还是建议升级到最新稳定版。

ImageMagick

ImageMagick是一个图象处理软件。它可以编辑、显示包括JPEG、TIFF、PNM、PNG、GIF和Photo CD在内的绝大多数当今最流行的图象格式。

影响范围:

  • ImageMagick 6.5.7-8 2012-08-17
  • ImageMagick 6.7.7-10 2014-03-06 低版本至6.9.3-9released 2016-04-30

漏洞详情&修复参考:

这个漏洞爆出来时也是被刷屏的,各大互联网公司都纷纷中招,利用一张构造的图片使用管道服符让其执行反弹shell拿到服务器权限,产生原因是因为字符过滤不严谨所导致的执行代码.对于文件名传递给后端的命令过滤不足,导致允许多种文件格式转换过程中远程执行代码。

3.应用安全隐患

为了不加长篇幅长度,加固具体步骤可以自行搜索。

SSH

之前有人做过实验把一台刚初始化好的机器放公网上看多久会遭受到攻击,结果半个小时就有IP开始爆破SSH的密码,网上通过SSH弱密码进服务器的案列也比比皆是。

安全隐患:

  • 弱密码

加固建议:

  • 禁止使用密码登录,更改为使用KEY登录
  • 禁止root用户登录,通过普通权限通过连接后sudo到root用户
  • 修改默认端口(默认端口为22)

Redis

Redis默认是没有密码的,在不需要密码访问的情况下是非常危险的一件事,攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法,可以成功在 Redis 服务器上写入公钥,进而可以使用对应私钥直接登录目标服务器。

安全隐患:

  • 未认证访问
  • 开放公网访问

加固建议:

  • 禁止把Redis直接暴露在公网
  • 添加认证,访问服务必须使用密码

Jenkins

Jenkins在公司中出现的频率也特别频繁,从集成测试到自动部署都可以使用Jenkins来完成,默认情况下Jenkins面板中用户可以选择执行脚本界面来操作一些系统层命令,攻击者通过暴力破解用户密码进脚本执行界面从而获取服务器权限。

安全隐患:

  • 登录未设置密码或密码过于简单
  • 开放公网访问

加固建议:

  • 禁止把Jenkins直接暴露在公网
  • 添加认证,建议使用用户矩阵或者与JIRA打通,JIRA设置密码复杂度

Zookeeper

分布式的,开放源码的分布式应用程序协调服务;提供功能包括:配置维护、域名服务、分布式同步、组服务等。Zookeeper默认也是未授权就可以访问了,特别对于公网开放的Zookeeper来说,这也导致了信息泄露的存在。

安全隐患:

  • 开放公网访问
  • 未认证访问

加固建议:

  • 禁止把Zookeeper直接暴露在公网
  • 添加访问控制,根据情况选择对应方式(认证用户,用户名密码,指定IP)

Zabbix

Zabbix为运维使用的监控系统,可以对服务器各项指标做出监控报警,默认有一个不需要密码访问的用户(Guest)。可以通过手工SQL注入获取管理员用户名和密码甚至拿到session,一旦攻击者获取Zabbix登录权限,那么后果不堪设想。

安全隐患:

  • 开放公网访问
  • 未删除默认用户
  • 弱密码

加固建议:

  • 禁止把Zabbix直接暴露在公网
  • 删除默认用户
  • 加强密码复杂度

Elasticsearch

Elasticsearch是一个基于Lucene的搜索服务器。越来越多的公司使用ELK作为日志分析,Elasticsearch在低版本中存在漏洞可命令执行,通常安装后大家都会安装elasticsearch-head方便管理索引,由于默认是没有访问控制导致会出现安全隐患。

安全隐患:

  • 开放公网访问
  • 未认证访问
  • 低版本漏洞

加固建议:

  • 禁止把Zabbix直接暴露在公网
  • 删除默认用户
  • 升级至最新稳定版
  • 安装Shield安全插件

Docker

容器服务在互联网公司中出现的频率呈直线上升,越来越多的公司使用容器去代替原先的虚拟化技术,之前专门做过Docker安全的分析,从 Docker自身安全, DockerImages安全和Docker使用安全隐患进行展开,链接:https://toutiao.io/posts/2y9xx8/preview

之前看到一个外国哥们使用脏牛漏洞在容器中运行EXP跳出容器的视频,具体我还没有复现,如果有复现出来的大家一起交流下~

安全隐患:

  • Base镜像漏洞
  • 部署配置不当

加固建议:

  • 手动升级Base镜像打上对应补丁
  • 配置Swarm要当心

4.总结

当公司没有负责安全的同学,做到以下几点可以在一定程度上做到防护:

  1. 关注最新漏洞情况,选择性的进行修复;
  2. 梳理内部开放服务,了解哪些对外开放能内网访问的绝不开放公网;
  3. 开放公网的服务必须做好访问控制;
  4. 避免弱密码;避免弱密码;避免弱密码;

以上内容只是理想状态,实际情况即使有安全部门以上内容也不一定能全部做到,业务的快速迭代,开发安全意识的各不相同,跨部门沟通上出现问题等等都会导致出现问题,这篇文章只罗列了部分服务,还有很多服务也有同样的问题,我有空会不断的更新。WeChat:atiger77