Page 1 of 2 12 LastLast
Results 1 to 25 of 28

Thread: Strange Reading

  1. #1

    Strange Reading

    Hey all,

    I have a strange reading showing up on the netstat readout for my linux box. It shows one of our nameservers connected to ede.nl.eu.undernet.org:ircd in a Close_Wait status.

    Anyone know why this would be, and what ( if anything ) I should do about it?

    It has only showed up recently, and so I am kind of puzzled.

    Thanks.

  2. #2
    Do you allow shell access to others? Remote connections through PHP/Perl? If not, then try to find which process it's coming from, and run some rootkit detection programs. I'd recommend running them anyways.

  3. #3
    I don't allow shell access and I don't think I have ever set anything for or against remote connections with PHP or Perl. Where can I look to see if there are remote connections allowed?

  4. #4
    If you can do a netstat -np you could possibly see the program using it.

  5. #5
    My original netstat:
    root@enterprise [~]# netstat
    Active Internet connections (w/o servers)
    Proto Recv-Q Send-Q Local Address Foreign Address State
    tcp 1064 0 ns1.*.com:36014 ede.nl.eu.undernet.org:ircd CLOSE_WAIT
    My netstat -np readout:

    root@enterprise [~]# netstat -np
    Active Internet connections (w/o servers)
    Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
    tcp 1064 0 XXX.XXX.XX.XXX:36014 193.109.122.67:6667 CLOSE_WAIT 1491/[kjournald]
    tcp 187 0 XXX.XXX.XX.XXX:59671 193.109.122.67:6667 CLOSE_WAIT 1491/[kjournald]
    Anyonoe know why "kjournald" would be having my system connect with undernet ircd?

  6. #6
    There's a possiblility it's been compromised. Load up rkhunter and run it, and maybe a few others and see if it picks up anything.

  7. #7
    Join Date
    May 2005
    Posts
    280
    kjournald with pid 1491. Well, not impossible, but not likely either.
    Sure looks like some process masq'ing as kjournald.

    Maybe a look at /proc/1491 can give you a few tips ? /proc/1491/fd might also contain
    interesting information.

  8. #8
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,262
    Looks like you have a psybnc or something like that running. Follow the suggestion about looking in /proc. If that is the case you need to look into securing your server more.
    Steven Ciaburri | Proactive Linux Server Management - Rack911.com
    System Administration Extraordinaire | Follow us on twitter:@Rack911Labs
    Managed Servers (AS62710), Server Management, and Security Auditing.
    www.HostingSecList.com - Security notices for the hosting community.

  9. #9
    It seemed to be running multiple instances under the same PID . I simply killed it and it hasn't returned in the netstat readouts.

    Thanks for your help guys Greatly appreciated.

  10. #10
    Join Date
    May 2005
    Posts
    280
    You really should give the machine a reboot to see if it comes back, and also to make sure the _correct_ kjournald is running.

  11. #11
    maybe could be an: ircd or psybnc, something about the world of irc..
    Look in your /var/tmp, and see if you have got something of strange..

  12. #12
    How can I be sure the correct kjournald is running?

  13. #13
    WHM shows one at the following:

    PID 412 (kjournald)
    PID 1441 (kjournald)
    PID 1491 ([kjournald]) /usr/lib/sshdlib/[kjournald /usr/lib/sshdlib
    [kjournald]

  14. #14
    Join Date
    May 2005
    Posts
    280
    Quote Originally Posted by Calibur747
    WHM shows one at the following:

    PID 412 (kjournald)
    PID 1441 (kjournald)
    PID 1491 ([kjournald]) /usr/lib/sshdlib/[kjournald /usr/lib/sshdlib
    [kjournald]
    First, stop using WHM for this kind of thing. It is almost useless.

    And yes, your host is compromised.. 412 is the real kjournald process.
    You will also notice (if you use "ps auxww") that the real kjournald not only had a low pid, but it also has 0 RSS and VSZ.

    /usr/lib/sshdlib/ ? Good bet you have some trace of the backdoor there, but not 100% sure. It can be anywhere.

    So, in a nutshell, you are still compromised. And if the process has access to /usr/lib,
    then you better rebuild your box from scratch, cause ... well, it is not your box anything. It is the hacker's.

  15. #15
    Went to that directory and I found a bunch of files, including psybnc titled configs and scripts. I deleted this directory promptly.

    Any other suggestions?

  16. #16
    You will have to reformat, back up your data, then once it comes back up, have it secured, and restore data.

  17. #17
    Ok your box has been definitely compromised. Please do a

    ps auxww|grep kjournal

    If the owner of this process is root (one kjournald will and will look like [kjournald]) you have no hope and the system will have to be rebuilt. You will need some experience in security to find out what happened. If the owner is not root there is some hope but you have to do the following:

    - Find out how did it get there. If the process is owned by the apache user most likely it was some kind of cross scripting attack. Make sure you find out whats the vulnerable site and update it. It wont help if you rebuild the system before fixing this site because there are automated attacks so your systems will be compromised again. lsof is sometimes useful for this kind of problems.

    - If the system was not compromised as root there is no need to rebuild the system but you still got to clean up the mess. See what kind of files the bad process has opened and how it affects your system. On compromises there is no specific cleanup that you have to do since the cleanup is specific to the attack.

    - Although this is really bad, you can see it as a good thing since you will learn a lot from this process if its your first. Good luck
    Increase email deliverability and know who clicked and opened your emails.

    SendGrid, reliable SMTP service.

  18. #18
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,262
    I love how every one says that hes is root compromised and needs a os reload.

    Not once did we see if it was running as root....

    Getting a os reload is pointless unless he secures it, or has someone do it for him.
    Steven Ciaburri | Proactive Linux Server Management - Rack911.com
    System Administration Extraordinaire | Follow us on twitter:@Rack911Labs
    Managed Servers (AS62710), Server Management, and Security Auditing.
    www.HostingSecList.com - Security notices for the hosting community.

  19. #19
    Join Date
    Nov 2004
    Location
    Silicon Valley
    Posts
    569
    As a important side note, simply deleting folders / files wont make your problems go away. If they got there to begin with, you need to keep tracing back the problem to its source, not just clean up its work

  20. #20
    It is probably updating for some reason.

  21. #21
    Join Date
    Mar 2005
    Location
    Fremont, California
    Posts
    6
    You don't think it might have to do with an ext3 (journaled)
    file system, do you?

  22. #22
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,262
    Quote Originally Posted by amacrae
    You don't think it might have to do with an ext3 (journaled)
    file system, do you?
    There should only be one process running besides its not supposed to bind to a port

    root@enterprise [~]# netstat -np
    Active Internet connections (w/o servers)
    Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
    tcp 1064 0 XXX.XXX.XX.XXX:36014 193.109.122.67:6667 CLOSE_WAIT 1491/[kjournald]
    tcp 187 0 XXX.XXX.XX.XXX:59671 193.109.122.67:6667 CLOSE_WAIT 1491/[kjournald]

    He needs to secure the server, the problem will never go away if he does not do that.
    Steven Ciaburri | Proactive Linux Server Management - Rack911.com
    System Administration Extraordinaire | Follow us on twitter:@Rack911Labs
    Managed Servers (AS62710), Server Management, and Security Auditing.
    www.HostingSecList.com - Security notices for the hosting community.

  23. #23
    Join Date
    May 2005
    Posts
    280
    Quote Originally Posted by Steven
    I love how every one says that hes is root compromised and needs a os reload.

    Not once did we see if it was running as root....

    Getting a os reload is pointless unless he secures it, or has someone do it for him.
    You did notice the directory where the files where, right ?
    /usr/lib/sshdlib

    Considering nothing will create this directory by itself, during the compromise it was created. So, somehow, someone was able to create a directory inside /usr/lib.

    So even if the process is not running as root, it is a sure bet that at some point the compromise involved privileged (root) access.

  24. #24
    Quote Originally Posted by Steven
    I love how every one says that hes is root compromised and needs a os reload.

    Not once did we see if it was running as root....

    Getting a os reload is pointless unless he secures it, or has someone do it for him.
    ?????? Did you read my previous post?
    Increase email deliverability and know who clicked and opened your emails.

    SendGrid, reliable SMTP service.

  25. #25
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,262
    Quote Originally Posted by morcego
    You did notice the directory where the files where, right ?
    /usr/lib/sshdlib

    Considering nothing will create this directory by itself, during the compromise it was created. So, somehow, someone was able to create a directory inside /usr/lib.

    So even if the process is not running as root, it is a sure bet that at some point the compromise involved privileged (root) access.

    Do you know how many servers I have seen that have had poor permissions or permissions changed on a directory in an attempt to "fix" a problem? Without more information we cannot give a definate answer as to if it was root compromised or not.
    Steven Ciaburri | Proactive Linux Server Management - Rack911.com
    System Administration Extraordinaire | Follow us on twitter:@Rack911Labs
    Managed Servers (AS62710), Server Management, and Security Auditing.
    www.HostingSecList.com - Security notices for the hosting community.

Page 1 of 2 12 LastLast

Related Posts from theWHIR.com

Posting Permissions

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