3 thoughts on - How To Detect Botnet User On The Server ?

• This sounds like a good place to start:

  https://major.io/2011/03/09/strategies-for-detecting-a-compromised-linux-server/

  (look for open ports connections both inbound and outbound with netstat, etc.)

  But, if someone has completely breached the machine and gotten root on it, they could put in fake binaries that hide ports and hide processes from ‘top’ (or ps, lsof). So, a look via chkrootkit or rkhunter would be needed to find that.

  The link for rkhunter in the article is bad .. here is the new one:

  http://rkhunter.sourceforge.net/

  rkhunter seems to be in EPEL. chkrootkit is in fedora, it does not seem to be in EPEL.

• Another alternative is to use a FIMS/HIDS such as Aide (Advanced Intrusion Detection Environment), OSSEC or Samhain. Be prepared to learn a lot about what your OS normally does behind the scenes (and thus a fair amount of initial fine tuning to exclude those things). Aide seems to work well (I’ve seen only one odd result) and is quite granular. However, it is local system based rather than centralized and isn’t daemon based so you’re left with periodic checks and finding a way to protect the executable, database and configuration. OSSEC is centralized, daemon based and can check logs for anomalies. However, it is not nearly as granular as Aide and does produce false positives (for example, if ‘detect new files’ is used, it will detect based on access time changes rather than modification or change times – but only for a while…). If you select OSSEC, whatever you do, do NOT put extraneous files in /var/ossec/etc/shared – you can get truly bizarre and baffling results doing so.
  I only know about Samhain, if someone has experience I would very much like to hear about it’s strengths and weaknesses.

  —– Original Message —

• Intrusion about what your OS normally does behind the scenes (and thus a fair amount well local system based rather than centralized and isn’t daemon based so you’re left with periodic checks and finding a way to protect the executable, database and configuration. OSSEC is centralized, daemon based and can check logs for anomalies. However, it is not nearly as granular as Aide and does produce false positives (for example, if
  ‘detect than modification or change times – but only for a while…). If you select OSSEC, whatever you do, do NOT put extraneous files in much server. identify. etc.)

  And never trust anything executed on potentially compromised machine. Paranoia is your friend.

  ( Say with open ports: see what internally executed command netstat gives you, and compare that with external port scan from sane machine: say, using nmap, make sure to turn off internal firewall, and have nothing that filters packets between two boxes. Anything that you see externally and don’t see internally is a big red flag. However, the machine may be listening to one or few pinpoint “mother” IPs, so do not expect necessarily external scan detect those. )

  it, they could put in fake binaries that hide ports and hide processes from ‘top’ (or ps, lsof). So, a look via chkrootkit or rkhunter would be needed to find that. to be in EPEL.

  And after you follow all great advises people gave here, and finish with forensics: learn what led to compromise. Then do real recovery from compromise, which is: back up data, wipe compromised system, install fresh new latest system, fully update, configure it taking into consideration what you learned about compromise, install one of the host based or central “intrusion detection systems” that were recommended by others on this list. Then, update, update, update…

  Good luck!

  Valeri

  ++++++++++++++++++++++++++++++++++++++++
  Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
  ++++++++++++++++++++++++++++++++++++++++