Results 1 to 10 of 10
  1. #1
    Join Date
    May 2003
    Melbourne, Australia

    I Caught A Hacker - how do I hammer this guy?

    I had a recent signup and our Fraud protection gave a blank result for all aspects it checks - basically the IP was unknown. So I decided to allow the account to be created - BIG MISTAKE.

    The next few hours the server was hacked. I managed to lock him out again - terminated his account, removed all his (0) UID created users and groups etc. I totally diabled telnet and changed ssh settings. So I'm feel farily confident I locked him out now. anyway I wanted to know exactly what he did so I did a search for all the .bash_history files - his came up I had a look at it:
    he went straight into uploading an exploiter (root kit) and installed it and bang erased everything in his account and that was it. Now I'm wondering - has he set the server up for something bad in the coming days - anyway it doesn't matter I'm having the server cancelled in a days time, setting up a new server now.
    But here's what he uploaded via ftp:

    He then compiled it and the servers been stuffed ever since. Question - is this a kernal crack - meaning a serious one? Anyone had experience with this before.

    Anyway I have all his details - although they are prob all false - but I have his IP and the username he signed up with was smurfas

    Anyone got any suggestions how I deal with this from now? I'd love to get this guy caught - do I have enough info?

    Also should I be doing anything else to server right now? What's this mremap_pte.c do?

    Help much appreciated

  2. #2
    Join Date
    May 2003
    Melbourne, Australia
    I can look at the smurfas (his) user bash history - but as soon as he became root - I don't know what he did, he changed root bash_history file to a symbolic link to dev/null.
    I changed the systems root password myself twice , should I be doing anything else to the server right now?

  3. #3
    Ordering an OS Reinstall then getting a system admin to check it out and secure it, and I'm not sure what to do about the hacker.

    Edit: I saw your getting a new server thats fine but an os-reinstall would have been fine
    [email protected]
    MSN - [email protected]
    AIM - Badda Bing 0003

  4. #4
    Join Date
    Mar 2004
    change the ip if u can?
    nEw SeRvErs :: Comming soon ::

  5. #5
    Do you offer your users telnet / SSH1 / SSH2 access? I wouldn't suggest you do this. Force people to get themselves a dedicated/ VPS server for that. Remote console login is a huge security risk on shared hosts AFAIK.

  6. #6
    Join Date
    Jan 2003
    Houston, TX - Originally from UK
    Hoo yeah. SSH is never ever an option with us on shared accounts. Just to big a risk with all the delightful script kiddies knocking around.

    And don't ever enable Telnet! That's just asking for a whole boatload of trouble!
    Kinkamono Internet Services - The Internet. Done Right.
    Dive In...

  7. #7
    Join Date
    Apr 2003
    London, UK
    What kernel are/were you running? this is not a new exploit +3 months

  8. #8
    Join Date
    Mar 2004
    Like Loon said, if you have the latest kernel, the mremap Vulnerability wont affect you at all.

    What I would do is, take all his information up to his ISP ( his ip address), heck, even a small call to the FBI will take care of that.

  9. #9

    In today's age, telnet should be disabled by default; unfortunately that's something you have to remember to do.

    As stated, SSH should be protocol 2 and PermitEmptyPasswords set to no (uncommented).

    Look at to help with a lot of the PHP and CGI telnet type programs.

    Ensure your /tmp partition is set to nonexec, nosuid to help with keeping it from being used to compile programs.

    And if you can get away with it (if you allow users to SSH, you may not be able to do it), then change the permissions of your compilers and programs like wget (including lynx et all) to 700 so that only root can execute them.

    If you do have specific users who SSH, then you can create a SSH group and then assign the compiler and fetching program rights to that group.

    Lastly, if you do offer SSH, do get and check ID's.

    Personally, we don't recommend offering SSH on shared because most people (including our staff) are not trained to verify the accuracy of security documents (see the movie, "Catch me if you can.")

    Thank you.
    Peter M. Abraham
    LinkedIn Profile

  10. #10
    Join Date
    Mar 2003
    California USA
    Another case of the dreaded no kernel upgrade. Well there is not alot you can do to hammer him, it was usually a proxied attempt. I highly suggest you get an os restore and secure that server up tight.
    Steven Ciaburri | Proactive Linux Server Management -
    Managed Servers (AS62710), Server Management, and Security Auditing.

Posting Permissions

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