linux root password changes
Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: linux root password changes

  1. #1
    Junior Member
    Join Date
    Sep 2002
    Posts
    5

    linux root password changes

    Hi,

    We are running a web server on RED HAT linux 8.0. But the root password keeps on getting changed. We reset the password to new one. But after about one or two days the system again says that password is not accepted.

    We are running Apache, Mysql 3, a php based web site(which accesses mysql), Java SDk 1.4, A java program which accesses mysql(not accessible from internet.(Think so)).

    Can you plz advice me on what to do. Can a remote attacker change the root password.

    Thanks,
    Chamal.

  2. #2
    Junior Member
    Join Date
    Feb 2005
    Posts
    9
    Yes, if your box is owned, the attacker can change the root password at will. If your password keeps changing, and you are positive that it is not being done by someone else in you organization, who has authority, then your box is OWNED. It cannot be trusted at all. You need to take it offline, and either investigate it to figure out if you can find out how the attacker got in(this is preferable since you may find some security issues in your code) but maybe you do not have the skills to perform the forensic investigation, or the time, or the money to hire someone who can, so, below is what you probably should do.

    My advice for whatever it is worth:

    1. Take box offline.
    2. backup data.
    3. wipe box.
    4. reinstall, you might want to consider using fedora core 3 instead of RH8.
    5. bring box back online, behind a firewall that is not allowing inbound connections to it.
    6. install any required updates. if you still using redhat 8, I believe that there is a channel on the fedora core yum repository for security updates for rh8. info about updateing using yum on RH8 can be found here

    http://www.fedora.us/wiki/FedoraHOWTO

    7. decide what services you are going to be serving on this box, and then research them to acquire a basic knowledge about what issues there are with security. Specifically, look into php security, and apache, and any other services which are going to be open to connection from the outside world. Do you use phpBB? There are some issues with certain versions of that and you might need to upgrade or use a work arround. Have you investigated php security at all, are you sure your code is safe? I am not much of a php coder, but someone here can surely tell you the most common issues with security and php.

    8. Secure your applications and code to the best of your ability.

    8a. I would do this, but the config can be a bit daunting for a newb. Install tripwire, and then scan the machine to create a baseline which can be compared to later, and then if you have an issue again, you can KNOW what changes were made.

    9. Allow access to the services you require through the firewall again.

    It would also be nice if you setup an IDS which took a look at all traffic coming to and from that box. This may be daunting though if you do not have experience. You probably should take a brief look at snort, just to see if that may be something you want to delve into.

    EDIT:

    Some more things:

    Make sure you use a strong password for root

    Also, strong passwords for the mysql connections, and access control lists in mysql to determine exactly which users are allowed to connect to mysql from which boxes.

    you probably want to restrict remote management by ssh to only ip's that you know need it, if that is not possible, maybe look into port knocking, check out this site.

    http://www.soloport.com/iptables.html

    Also, make sure that your firewall is configured well. You want to use egress(outgoing) filtering as well as ingress(incoming) filtering. Only ports that are required for your external users should be allowed in, i.e. http, and ssh with access controll lists, or port knocking. Only ports that are required for the services you are offiering should be allowed out through the firewall. If that is the case, if someone does manage to exploit your code, or the httpd service, life is made more dificult for them to do anything usefull with the box, like connect to it for management, or initiate attacks onto other boxes.


  3. #3
    Senior Member
    Join Date
    Dec 2004
    Posts
    320
    before doing all that I would recommend check /etc/shadow or /etc/passwd for any back door accounts. If they are there delete them. Check your /var/log/ logs and see if anyone has been sshing or telneting in and what usernames they were using. If they are any good you won't see anything but it is worth a try. Also set up snort or another IDS to see if any attempts are made. check netstat -all and see if any odd ports are open. try ps /aux to see if any odd processes are running. Try a vulnerability scan on your box, and make sure you have all the most recent updates from Red Hat.
    The fool doth think he is wise, but the wiseman knows himself to be a fool - Good Ole Bill Shakespeare

  4. #4
    Junior Member
    Join Date
    Feb 2005
    Posts
    9
    Only problem with that is if his box is owned, it cannot be trusted. Ok, he finds a user account and deletes it. runs a vulerablility scan, fixes the vulnerabilities. Then runs ls to get a directory listing, or locate to find a file, or any other of a number of commands, and discovers after his box is compromised again, that he ran a custom version of ls, or locate, or whatever that installed a rootkit, added the some users, and somehow sent the original attacker a message that the box is now available again for his use.

    Also, you cannot get updates from RedHate anymore for redhat 8. Unless you use the method I mentioned, which is to install yum, and use the redhat 8 security update channel on the fedora yum repository. Or you could pay money to a third party who is maintaining redhat 8.

    If someone unidentified has root level access to the box, it cannot be trusted AT ALL, unless you have a good(saved on CD or other external write once media) tripwire database (or some other file system integrity check)and can use that to KNOW what changes have been made, and then fix those items which have been changed.

    Yes my post was long, had lots of suggestions, but the bottom line is,

    Backup data,
    reinstall
    patch
    secure
    restores data
    make available to outside world again.

    That really isn't "all that" much to do, especially if they are using this box for anything important. It needs to be fixed, and made secure, and most of all TRUSTED.

  5. #5
    Leftie Linux Lover the_JinX's Avatar
    Join Date
    Nov 2001
    Location
    Beverwijk Netherlands
    Posts
    2,535
    how upto date was that redhat 8 box ??

    I'd say own fault.. but still take caution and make sure you only backup the website, non of that we'll clean out the box stuff..
    I have an updating list of zombie linux boxes with a php worm or something..
    They seem to have a weird port open with a shell as user nobody, and there are numbers of exploits for oder linux (kernel) versions and other common sotfware found on linux servers. there's numbers of possible ways to get root on servers with sloppy update routines

    Start with a fresh up to date linux distribution and keep your server up to date..
    ASCII stupid question, get a stupid ANSI.
    When in Russia, pet a PETSCII.

    Get your ass over to SLAYRadio the best station for C64 Remixes !

  6. #6
    Senior Member
    Join Date
    Dec 2004
    Posts
    320
    damn, I guess I didn't think too much before my first post. You guys are right. the wipe and Format and re-install thing is probably a better idea.
    The fool doth think he is wise, but the wiseman knows himself to be a fool - Good Ole Bill Shakespeare

  7. #7
    Senior Member Maestr0's Avatar
    Join Date
    May 2003
    Posts
    604
    I would still try and figure out how/and where the compromise happened. If you TOUCH that box w/o making a legal forensic backup (depends state-to-state whats considered legal) than you just threw your case out of court. After you clone the system (Your state law-enforecement may have to come use their own ****) you can have the orignal bagged and tagged as they say, and work from the duplicate. Using known good binaries is standard practice, there are plenty of CD based security CD's like KNOPPIX or INSERT which will provide them. Even if you dont use the box again its always good to:
    A. Have a case to prosecute if so desired.
    B. Know what happened so it won't happen again.

    I would CHECK YOUR LOGS. Its what they are there for.

    -Maestr0

    http://www.securityfocus.com/infocus/1811
    http://www.rootkit.nl/
    http://www.chkrootkit.org/

    EDIT: On closer inspection, I notice Chamal isnt in the US, so I have no idea how this affects your legal standing, the rest still applies.
    \"If computers are to become smart enough to design their own successors, initiating a process that will lead to God-like omniscience after a number of ever swifter passages from one generation of computers to the next, someone is going to have to write the software that gets the process going, and humans have given absolutely no evidence of being able to write such software.\" -Jaron Lanier

  8. #8
    Banned
    Join Date
    Dec 2004
    Posts
    53
    reinstall, you might want to consider using fedora core 3 instead of RH8.
    If this is for a company, then DO NOT use FC3. FC series is purley beta testing, and is purposly filled with experimental drivers/programs/functonality. This is because it is a testing playground for their company based product: RedHat Enterprise. I can't imagine what the built in SELinux patches would do to his php server permissions.

  9. #9
    Junior Member
    Join Date
    Sep 2002
    Posts
    5

    log files

    Hi guys,

    Thanks a lot for your replies. They were so useful.

    I do not have much experience in handling log file. Can you advice me on the things that I should search inside log files.

    Best regards,
    Chamal.

  10. #10
    Senior Member
    Join Date
    Dec 2004
    Posts
    320
    <ramble>
    Check for 'failed password' or 'bad login attempt' something of that sort. Look through the /var/secure logs. Also I would look for sshd or telnet connections. It will say something like
    Jan 15 12:34:56 | localhost | |program name| start : | program Id # | | from (now this is the line to pay attention to) | somewhere(IP address of who connected to the server process)
    I would also check to see if there are any server processes running (daemon I believe is the correct term) that you didn't set to run. If you never set up ssh and there is a ssh daemon running, get worried. Same with telnet. (although the telnet daemon is part of the xinetd process if I remember correctly)
    type 'chkconfig --list' (you might want to try 'chkconfig --list | more') and look under the xinetd based services, see if telnet is running under that. sshd should be it's own seperate process.

    ... or they could've put in an backdoor ...

    for that, you probably want to check what is listening on what port. type netstat -all | more see anything odd ? (This is all mentioned in my first post so I don't know why I am going over it again ) just remember that if your box is owned, don't trust it.

    </ramble>
    The fool doth think he is wise, but the wiseman knows himself to be a fool - Good Ole Bill Shakespeare

Posting Permissions

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

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides