Keep learning, keep living...

0%

发表于 更新于 分类于

SSH不仅可以使用远程管理主机，还可以利用SSH客户端和SSH服务器之间的加密连接为其他服务实际中继服务，这一般称为SSH隧道(SSH Tunneling)或者SSH端口转发。

SSH端口转发分为三种类型:

  • 动态端口转发
  • 本地端口转发
  • 远程端口转发

无论是哪种端口转发，整个过程都涉及四个角色:

  • 业务客户端
  • SSH客户端
  • SSH服务器
  • 业务服务端

这些角色进程并不要求都位于独立主机上，它们可以位于同一台主机上，使用localhost或者127.0.0.1进行网络访问。

本文基于这4种角色来简要说明这三种端口转发的过程。三种端口转发都依赖SSH客户端和SSH服务器建立一个加密连接在二者之间转发数据。

阅读全文 »

发表于 更新于 分类于

近期我们的BASH脚本中遇到一个BUG，最终分析到是变量值为空时没有用""包裹导致的。

我们使用一个测试脚本来进行分析。测试脚本t.sh内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/bin/bash

kof=""

if [ ! -f $kof ]; then
    echo "1"
fi

if [ ! -f "$kof" ]; then
    echo "2"
fi

echo "END"

测试脚本的执行结果如下:

1
2
3
[root@default ~]# bash t.sh
2
END

可以看到当变量$kof为空时，第一个if语句块中的语句没有被执行，而第二个if语句块中的语句被执行了。这两个语句块的差别就在于第二个语句块中的$kof变量用""进行了包裹。

阅读全文 »

发表于 更新于 分类于

近期遇到一个服务器上内核模块无法卸载的问题。执行rmmod命令返回错误信息:

1
Device or resource busy

通过Google搜索，发现其他人也遇到过类似的问题，原因基本指向是编译内核模块的gcc版本和编译内核的gcc版本不一致。

于是开始检查我们的环境。

阅读全文 »

发表于 更新于 分类于

seccomp代表secure computing，是早在2.6.12版本就引入到内核的特性，用来限制进程可以使用的系统调用。它作用于进程里的线程(task)。

最初，seccomp只允许使用read, write, _exit, sigreturn4个系统调用，调用其他系统调用时，内核会发送SIGKILL信号终止进程。当时seccomp的提出主要是想用于出租空闲的CPU算力。这种模式叫做STRICT模式。它限制过于严格，在实际应用上并没有太多发展。Linus Torvald甚至建议把它从内核中砍掉。

阅读全文 »

发表于 更新于 分类于

OTP是One Time Password的缩写，是进一步加强身份认证的安全性的校验方法, 一般配合常规密码一起使用。OTP动态生成，只使用一次。手机验证码就是典型的OTP方式。用户请求一个短信验证码, 服务器随机生成一个验证码，然后临时存储起来，通过短信发送给用户。用户在系统上输入验证码发送回服务器，服务器根据临时存储的验证码进行校验。

生成OTP业内有许多标准算法，比如SHA-1。所有这些算法都包括两部分输入:

  • 种子值(seed)：静态值，和帐号关联的密钥
  • 可变因子(moving factor)：每次生成OTP都变化的部分
阅读全文 »

发表于 更新于 分类于

之前的文章<<使用eBPF和BCC调查创建文件的进程>>介绍了基于BCC来实现eBPF程序。BCC实现了对eBPF的封装，用户态部分提供Python API, 内核态部分使用的eBPF程序还是通过C语言来实现。运行时BCC会把eBPF的C程序编译成字节码、加载到内核执行，最后再通过用户空间的前端程序获取执行状态。
可以在BCC的BPF调用中，指定参数debug=4, 我们可以看到BCC的执行过程, 如:

1
2
3
4
5
6
7
from bcc import BPF
BPF(text="""
#include <linux/ptrace.h>
int kprobe__tty_write(struct pt_regs *ctx, struct file *file, const char __user *buf, size_t count) {
return 0;
}
""", debug=4)

eBPF编程的门槛还是比较高的，在当前还是快速发展的情况，API也还不稳定，对程序员的C语言、编译过程和内核等知识都有比较高的要求。BCC把这些都封装起来给用户提供了一个更为简单的使用框架。但本身也存在的一些问题，比如:

  • 每次执行时都需要重新编译
  • 执行程序的机器都需要安装内核头文件

eBPF: extended Berkeley Packet Filter是对BPF(现在称为cBPF: classic BPF)的扩展, 现在尽管还叫做BPF, 但应用场景已经远远超过了它的名称的范畴。它的应用范围的扩大主要得益于这几方面:

  • 内核中BPF字节码虚拟机扩展为一个通用的执行引擎
  • 执行可节码的安全校验
  • JIT支持，可以直接将字节码指令转成内核可执行的原生指令运行

这样在安全性、可编程性和性能方面的提升都使得eBPF在包过滤以外的其他领域获取巨大的应用空间。

阅读全文 »

发表于 更新于 分类于

在我们的一个CentOS 7.8系统上，/tmp目录下偶尔会有一些随机名称的文件产生。业务比较久远，已经不清楚这些文件的来源，需要确定是哪个进程在创建它们。

Linux以VFS: Virtual File System通用文件模型的方式在物理存储介质上的文件系统和用户接口之间建立一个虚拟文件系统的抽象层。其中最重要的两个结构是:

  • inode: 存放文件的一般信息，每个inode结构都有自己的编号，这个号码唯一标识了文件系统中的文件。
  • dentry: 存放文件名称信息，以及与对应文件进行链接的有关信息。

VFS创建文件的最主要的步骤是:

  1. 为要创建的文件创建一个dentry结构
  2. 为要创建的文件创建一个inode结构并分配inode编号
  3. 将inode编号和文件名映射关系保存在所分配的dentry结构中
  4. 将dentry写入到父目录的数据区
阅读全文 »

发表于 更新于 分类于

SOCKS是一个比较简单的通用代理协议，用于在客户端与服务器之间代理网络数据包。最新的版本是5, 所以一般叫做SOCKS5，协议规范是RFC1928。但SOCKS5并不兼容之前的SOCKS4和SOCKS4A。SOCKS5在SOCKS4的基础上添加了UDP转发功能和校验机制。

SOCKS5的工作过程简单可以归纳为协商、请求、和转发三个阶段。以TCP代理场景来看, 一般流程是:

  1. 客户端建立TCP连接
  2. 客户端发送客户端侧支持的校验方法
  3. 服务端回应选择的校验方法
  4. 客户端和服务端之间按选择的校验方法完成校验
  5. 客户端发送所需的请求给服务端。SOCKS5支持不同的请求类型，包括CONNECT, BIND, UDPASSOCIATE等。
  6. 服务端接收到请求，从中解析出目的地址，建立到目的地址的连接。
  7. 发送成功信息给客户端。
  8. 客户端开始发送应用层信息。
  9. 服务端在客户端和目的地址之间转发应用层信息。

其中，2-4完成协商阶段，5-7完成请求阶段，之后进入转发阶段。

当前常用的校验方法是USERNAME/PASSWORD(RFC1929)和GSS-API(RFC1961)，具体的校验过程是由不同校验方法来自定义的。

使用USERNAME/PASSWORD校验方法的TCP代理时序图如下:

阅读全文 »

发表于 更新于 分类于

我们的业务Docker镜像是在centos/systemd镜像基础上构建的，业务进程由systemd来启动。最近需要对业务逻辑进行改造，需要识别传入的环境变量。看上去是相当简单的改动，但在我们的进程中加入读取环境变量的逻辑却发现读取不到传入的变量内容，最终定位原因是在systemd的环境变量的处理。

阅读全文 »

发表于 更新于 分类于

在一台CentOS 7.0服务器(内核版本号:3.10.0-123.el7.x86_64)上安装我们的安全防护程序后，会出现curl访问网址超时5秒的情况。现象如下:

1
2
3
4
5
[root@localhost ~]# time curl -s www.baidu.com -o /dev/null

real	0m5.120s
user	0m0.002s
sys	0m0.009s

通过strace分析程序调用的过程:

1
strace -f -tt -o curl.strace curl -s www.baidu.com -o /dev/null

从strace输出可以看到, 第一次curl调用sendmmsg同时发送了两个DNS数据包，分别是A记录和AAAA记录请求，但是只收到了A记录响应包:

然后等待5秒超时后，依次调用sendto和recvfrom串行处理两个DNS请求, 这次两个DNS响应全部收到后，继续向下执行:

而从抓包结果分析，tcpdump只能看到第一次同时发送的两个DNS请求中的A记录请求，AAAA记录请求数据包被内核协议栈丢弃了:

1
2
3
4
5
6
17:04:24.772049 IP 10.10.10.89.57416 > 114.114.114.114.53: 37081+ A? www.baidu.com. (31)
17:04:24.773693 IP 114.114.114.114.53 > 10.10.10.89.57416: 37081 3/0/0 CNAME www.a.shifen.com., A 180.101.49.12, A 180.101.49.11 (90)
17:04:29.776474 IP 10.10.10.89.57416 > 114.114.114.114.53: 37081+ A? www.baidu.com. (31)
17:04:29.778694 IP 114.114.114.114.53 > 10.10.10.89.57416: 37081 3/0/0 CNAME www.a.shifen.com., A 180.101.49.11, A 180.101.49.12 (90)
17:04:29.778925 IP 10.10.10.89.57416 > 114.114.114.114.53: 42471+ AAAA? www.baidu.com. (31)
17:04:29.780523 IP 114.114.114.114.53 > 10.10.10.89.57416: 42471 1/1/0 CNAME www.a.shifen.com. (115)
阅读全文 »