Port 2128 backdoor?

[saverio_miroddi]

One of the routine checkers (rkhunter) in our systems reported a warning for a backdoor on
port tcp 2128, which in subsequent checks disappeared.
The system now looks fine.

Now, I couldn't find anything detailed around the net, except that in past versions of
rkhunter, that port corresponded to some 'MRK' malware.

Does anybody have any pointer?
Which is the most appropriate strategy to adopt in these cases? Total disconnection &
reinstall in case I don't find any better informations?
IPTables/checkers/antivirus all report the system as fine.

Thanks!
Saverio

[unspawn]

One of the routine checkers (rkhunter) in our systems reported a warning for a backdoor on port tcp 2128, which in subsequent checks disappeared.

Then it could have been a transient connection or in older versions of RKH the port check match being too greedy picking up ports on the remote side as well.

The system now looks fine.

"Looks fine" as in you "feel" you shouldn't "worry" or "looks fine" as in you have verified ports in listening state?

Which is the most appropriate strategy to adopt in these cases? Total disconnection & reinstall in case I don't find any better informations? IPTables/checkers/antivirus all report the system as fine.

The appropriate strategy is to use other tools to determine if the warning can be corroborated or not. This will be a combination of file verification possibilities package management offers, using another tool in the same class like Chkrootkit or OSSEC HIDS or (unhide-tcp, netstat lsof, fuser), running a check with a filesystem integrity checker (if deployed before the warning) like Samhain, Aide or even tripwire and reading back logs and auth data for anomalies.

Yes, this could easily have been a false positive and therefore a lot of people will say "don't worry" but that simply is not the right approach.

[saverio_miroddi]

by "look fine" I meant that I checked the listening ports and there was nothing suspicious.
of course I verified that no files had been tampered (we have different integrity checkers running).

unhide gave several ports in the result - changing every time.

for now, we think the cause has been snort - it was running, so it's like to have been conflicting.

[unspawn]

by "look fine" I meant that I checked the listening ports and there was nothing suspicious.
of course I verified that no files had been tampered (we have different integrity checkers running).

Good work.

unhide gave several ports in the result - changing every time.

for now, we think the cause has been snort - it was running, so it's like to have been conflicting.

It shouldn't. Yes, Snort listens for traffic, but not bound to any ports. Your 'unhide' results, transient TCP ports > 1024 being used, should point to client-server traffic (also see the ip_local_port_range sysctl) and temporarily running tcpdump or inserting iptables "-j LOG" rules should show.