If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

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

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.

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.

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

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.

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 !

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.

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

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.

<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