How to detect malicious code sending information to attacker's server in linux

Question

Suppose you have some malicious code on your linux laptop, for example a rootkit or trojan or something like that. Now restrict your attention to the case that the malicious code does transfer some information to the hacker over the internet, for example because the hacker wants to steal some files from your computer or your passwords via a keylogger or because he wants to use your machine as a base to hack for example a company or government server.

Being a layman on network security I assume that it should be possible just to redirect (for example via ARP-spoofing or something like that) all traffic of your box (A) over another not compromised box (B) and see by sniffing if there is any suspicious traffic. This seems to be easy if you know that A shouldn't send any traffic at the moment (because you don't browse the web and so on...). However the malicious code could be a bit cleverer and send data only if there is some other traffic outgoing from (A), for example when you are surfing in the web. Then you would need a method to generate controlled traffic outgoing from machine A. Machine B then should know what traffic is when generated, i.e. to expect and should be able to find the additional traffic and detect this way the virus when it reports to the server.

I guess this model is a bit naive, but I want to learn more technical details about this point:

• How close is my above description to reality?
• What other, more sophisticated methods may the virus use to mask its send of information?
• If the described sniffing is a good method to detect such code when the code reports back to server, how would one actually do this in detail (in linux)? And how to make sure to detect even very smart ways to mask the sending of information?

Answer 1

it really depends on how deep teh attacker is in your system; if he's controlling your DNS then this will be a little tricky; if an attacker is already on your server, youre doomed anyway; there are a lot of hidden backchannels that are not easy to detect or command-channels using twitter, p2p, dns-queries etc pp; search SANS-ISC Reading-Room for "hidden channels" to get an idea of what might be possible

redirect ... and see by sniffing if there is any suspicious traffic

nearly impossible; heuristics dont work. and what do you do with encrypted traffic?

for controlling http-requests:

• use squid as a transparent proxy and use a whitelist with allowed connection-targets

for general networking-control

• use strict iptables-setup infront of your server (DENY anything, allow what is needed)
• log any outgoing connection-attempt for later analysis
• use tcpdump to record any traffic (dont forget UDP)