トリックを公開する時が来ました。
最初に以下をお読みください：https：
//blog.csdn.net/dog250/article/details/108113329
記事で説明されているトリックに従って、2つのプロセスのtcp接続の属性をハックしましょう。まず、ハックの前のシーンを示します。
[root@localhost ~]# netstat -ntp
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.56.110:22 192.168.56.1:55287 ESTABLISHED 1344/sshd: root@pts
tcp 0 0 192.168.56.110:22 192.168.56.1:55589 ESTABLISHED 4791/sshd: root@pts
次に、ハックを実装した後、プロセスが属するtcp接続が交換されます。
[root@localhost ~]# netstat -ntp
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.56.110:22 192.168.56.1:55287 ESTABLISHED 4791/sshd: root@pts
tcp 0 0 192.168.56.110:22 192.168.56.1:55589 ESTABLISHED 1344/sshd: root@pts
システムの運用と保守、または他の管理者がこのような状況に遭遇した場合、どのプロセスをデバッグの対象にする必要がありますか？
注⚠️、イベント後の前提を放棄する必要があります。実際には、接続が交換されたことに気付かず、多くの人を集めて会議を行った後、久しぶりに何かがおかしいことに気付かない場合があります。
私がそこにいたら、このようなことは起こりませんでした。職人として、ツールを使って迂回するのではなく、本質に直接向き合うことを好みます。私の意見では、tcp接続とprocfsを介したプロセスとの関係を見つけることはラウンドアバウト。
なぜそれを指さないのですか？
次の図を検討してください。取り外し不可能な手がかりを
介してピースがtcp_sockとソケットを関連付ける場合、迂回する必要はありませんか？
OK、次のコードはそれを行う方法を説明しています：
#!/usr/bin/stap -g
// tcpstat(.stp)
%{
#include <net/tcp.h>
#include <linux/fdtable.h>
struct result {
char laddr[16];
char raddr[16];
unsigned short lport;
unsigned short rport;
unsigned long ino;
int pid;
char comm[32];
};
static inline void ip2str(char *to, unsigned int from)
{
int size = snprintf(to, 16, "%pI4", &from);
to[size] = '\0';
}
void traverse(struct sock *sk, unsigned long ino, struct result *ret)
{
struct task_struct *tsk;
int i;
for_each_process(tsk) {
struct file *file;
for (i = 0; i < tsk->files->fdt->max_fds; i++) {
file = tsk->files->fdt->fd[i];
if (file == NULL) {
continue;
}
if (file->f_inode->i_ino == ino) {
char laddr[16], raddr[16];
ip2str(laddr, inet_sk(sk)->inet_rcv_saddr);
ip2str(raddr, inet_sk(sk)->inet_daddr);
memcpy(&ret->laddr[0], laddr, 16);
memcpy(&ret->raddr[0], raddr, 16);
ret->lport = sk->sk_num;
ret->rport = htons(sk->sk_dport);
ret->ino = ino;
ret->pid = tsk->pid;
memcpy(&ret->comm[0], tsk->comm, 32);
}
}
}
}
%}
function dump_tcp_info()
%{
struct task_struct *tsk;
struct inet_hashinfo *hashinfo = &tcp_hashinfo;
struct hlist_nulls_node *node;
struct socket_alloc *sa;
struct sock *sk;
struct result ret;
int i, ino;
for (i = 0; i < INET_LHTABLE_SIZE; i++) {
struct inet_listen_hashbucket *ilb;
ilb = &hashinfo->listening_hash[i];
sk_nulls_for_each(sk, node, &ilb->head) {
unsigned long ino;
sa = (struct socket_alloc *)sk->sk_socket;
ino = sa->vfs_inode.i_ino;
traverse(sk, ino, &ret);
STAP_PRINTF("LISTEN %s:%d inode:%d/[%d] %s\n",
ret.laddr,
ret.lport,
ret.ino,
ret.pid,
ret.comm);
}
}
for (i = 0; i <= hashinfo->ehash_mask; i++) {
struct inet_ehash_bucket *head = &hashinfo->ehash[i];
if (hlist_nulls_empty(&head->chain)) {
continue;
}
sk_nulls_for_each(sk, node, &head->chain) {
unsigned long ino;
sa = (struct socket_alloc *)sk->sk_socket;
ino = sa->vfs_inode.i_ino;
traverse(sk, ino, &ret);
STAP_PRINTF("ESTABLISHED %s:%d %s:%d inode:%d/[%d] %s\n",
ret.laddr,
ret.lport,
ret.raddr,
ret.rport,
ret.ino,
ret.pid,
ret.comm);
}
}
%}
probe begin
{
dump_tcp_info();
exit();
}
さあ、上記のスクリプトを実行して、ハッキングされたシステムについての真実を見つけてみましょう。
[root@localhost test]# ./tcpstat
LISTEN 0.0.0.0:22 inode:22852/[1001] sshd
LISTEN 0.0.0.0:22 inode:22850/[1001] sshd
ESTABLISHED 192.168.56.110:22 192.168.56.1:55287 inode:25510/[1344] sshd
ESTABLISHED 192.168.56.110:22 192.168.56.1:55589 inode:28747/[4791] sshd
この結果を使用して、ハッキングされた後の状況を比較します。
[root@localhost ~]# netstat -ntp
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.56.110:22 192.168.56.1:55287 ESTABLISHED 4791/sshd: root@pts
tcp 0 0 192.168.56.110:22 192.168.56.1:55589 ESTABLISHED 1344/sshd: root@pts
ハハ、真実が明かされる！
職人とは？大規模な道具に頼らないでください、専門家の知識に頼らないでください、それは跡のない小さな町の鍋を修理する人でもあります。もちろん、革靴も作れます。
浙江文州の革靴は濡れているので、雨でも太りません。