Linux ssh tunnel backdoor and Detection

I just discussed it with the two heroes in the group. I will summarize it and share it with you.

Now there is an intranet machine S6 and an Internet machine S7. We need to connect from S6 back to S7.

Run

Ssh-R 4022: localhost: 22 s7

At this time, the system will log in to S7, and a 4022 tunnel port will be opened locally in S7 to access IPv6.

Then execute ssh localhost-p 4022 in S7 and connect to IPv6.

Of course, you can also make a socks5 proxy to transfer it out, but I don't need it. If you need it, try man ssh on your own. In addition, you can also avoid shell, which is more concealed, or change the parameter.

In this scenario:

1. ssh is replaced and no logs are logged.

2. Write a simple C program and compile it into ELF. Then, execute the ssh injection and exit. J: If this ELF is encrypted, strings won't be available.

3. Use crontab to regularly execute this ELF. What if it is placed below?

[Root @ S6 ~] # Ls/etc/cron
Cron. d/cron. deny cron. monthly/crontab
Cron. daily/cron. hourly/cron. weekly/

How can we discover and defend against such backdoors? What should I do before, during, and after?

Beforehand:

As a management private network, the managed server can only accept active access from the management private network management end.

Access control: the firewall is completely prohibited from going out, and you are also prohibited from actively accessing the management end.

Well, these two are relatively effective, but there are certain costs and conditions.

In-process:

Check whether ssh has been replaced.

Grep/proc/line feature searching

Afterwards:

Check whether ssh is replaced. If no, check the log.

If... What if this is a reconnection Trojan? Only work in advance is effective. Ssh does not generate any additional files, but it is not that obvious. There are also processes, but not obvious. No need to hide files and processes :)

You can share your ideas. I think the host detection is too difficult.