Find the answer to your Linux question:
Results 1 to 4 of 4
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, ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jun 2009
    Posts
    3

    Unhappy Port 2128 backdoor?


    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

  2. #2
    Just Joined!
    Join Date
    Aug 2009
    Posts
    83
    Quote Originally Posted by saverio_miroddi View Post
    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.


    Quote Originally Posted by saverio_miroddi View Post
    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?


    Quote Originally Posted by saverio_miroddi View Post
    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.

  3. #3
    Just Joined!
    Join Date
    Jun 2009
    Posts
    3
    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.

  4. $spacer_open
    $spacer_close
  5. #4
    Just Joined!
    Join Date
    Aug 2009
    Posts
    83
    Quote Originally Posted by saverio_miroddi View Post
    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.


    Quote Originally Posted by saverio_miroddi View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •