I am logged in as root, which is the owner of sshd_config. When using lsattr, I can see that the file has s----ia---- set. I however cannot remove the immutable flag using chattr -i sshd_config. Any ideas??

Well, first I would check the integrity of the package openssh-server (through yum verify or rpm -V if you're running a Red Hat based OS). A full check with rkhunter is strongly advised.

Firstly, please excuse me if I don't make total sense. I have just dipped my toes into linux. With that said, I have taken your advice and when running rpm -V openssh, I am shown:
S.5....T /usr/bin/ssh-keygen. Please correct me if I am wrong, but this should not be there. I have attempted to install rkhunter without much luck as I get a 404 error when attempting to download the file. I will continue to install rkhunter. I do however have chkrootkit installed and have it set up to send emails daily now and it seems there are no infected files, but there have been quite a few failed logins/illegal users. Could this be because of the ssh-keygen? It seems this server has been taken full advantage of. Thanks for the help.

I hope you logged in (over the network?) as unprivileged user, then used 'su' to become root?


No files should have the append or immutable flag set by default and without the admins knowledge. (The "s" flag doesn't make sense BTW: see 'man chattr'.)


Indeed. Even if you would have used prelink (don't know if that's still on by default) the hash (the "5" in the output) should still match. Now execute to check all packages (esp. openssh-server), check all users shell history, look in /home, /tmp, /var/tmp, your docroot and other regular places for anomalous files (binaries, tarballs, files owned by root or the web server, etc, etc) and check your 'lastlog; last -wai' and all log files in /var/log for clues.


Unfortunately those tools should be installed before and not after a suspected compromise.


Chkrootkit hasn't been maintained for a couple of years.


Please investigate and report back before reaching that conclusion.

I did, but as of now the config file allows someone to log in from root alone. This is what I was attempting to change when I ran into all of this.

When it comes to executing the code, rpm -Va|grep -v "^\.\{8\}"
I am unsure as to what I am even looking for.

In addition I was actually able to install rkhunter. There were no rootkits found, I did however receive several warnings:

Checking system commands -> Performing file properties check:
usr/bin/chattr
usr/bin/groups
usr/bin/GET
usr/bin/lld
usr/bin/whatis/
sbin/ifup
sbin/ifdown

On the Trojan specific checks:
enabled xinetd services (could be Plesk related)

On Performing file system checks:
Checking /dev for suspicious file types
Checking for hidden files and directories

Checking Application Versions:
Checking version of Apache
Checking version of OpenSSL
Checking version of PHP
Checking version of Open SSH

For a total of 7/140 suspect files, 0/316 rootkits, and 4/8 suspect applications.

After viewing the logs here is a list of all warnings...

[11:26:44] /usr/bin/groups [ Warning ]
[11:26:44] Warning: The command '/usr/bin/groups' has been replaced by a script: /usr/bin/groups: Bourne shell script text executable

[11:26:45] /usr/bin/ldd [ Warning ]
[11:26:45] Warning: The command '/usr/bin/ldd' has been replaced by a script: /usr/bin/ldd: Bourne shell script text executable

[11:26:54] /usr/bin/whatis [ Warning ]
[11:26:54] Warning: The command '/usr/bin/whatis' has been replaced by a script: /usr/bin/whatis: Bourne shell script text executable

[11:27:02] /sbin/ifdown [ Warning ]
[11:27:02] Warning: The command '/sbin/ifdown' has been replaced by a script: /sbin/ifdown: Bourne-Again shell script text executable


[11:27:02] /sbin/ifup [ Warning ]
[11:27:03] Warning: The command '/sbin/ifup' has been replaced by a script: /sbin/ifup: Bourne-Again shell script text executable

[11:29:16] Checking '/etc/xinetd.d/bpcd' for enabled services [ Warning ]
[11:29:16] Checking '/etc/xinetd.d/bpjava-msvc' for enabled services [ Warning ]
[11:29:16] Checking '/etc/xinetd.d/client_smtp' for enabled services [ Warning ]
[11:29:17] Checking '/etc/xinetd.d/ftp_psa' for enabled services [ Warning ]
[11:29:17] Checking '/etc/xinetd.d/poppassd_psa' for enabled services [ Warning ]
[11:29:17] Checking '/etc/xinetd.d/smtp_psa' for enabled services [ Warning ]
[11:29:17] Checking '/etc/xinetd.d/smtps_psa' for enabled services [ Warning ]
[11:29:17] Checking '/etc/xinetd.d/submission_psa' for enabled services [ Warning ]
[] Checking '/etc/xinetd.d/bpcd' for enabled services [ Warning ]
[11:29:16] Checking '/etc/xinetd.d/bpjava-msvc' for enabled services [ Warning ]


[11:30:02] Checking if SSH root access is allowed [ Warning ]
[11:30:02] Warning: The SSH configuration option 'PermitRootLogin' has not been set.
The default value may be 'yes', to allow root access.
[11:30:02] Checking if SSH protocol v1 is allowed [ Warning ]
[11:30:02] Warning: The SSH configuration option 'Protocol' has not been set.



[11:30:03] Checking /dev for suspicious file types [ Warning ]
[11:30:03] Warning: Suspicious file types found in /dev:
[11:30:03] /dev/.udev/db//class/input/input1/event1: ASCII text
[11:30:03] /dev/.udev/db//block/sda/sda2: ASCII text
[11:30:03] /dev/.udev/db//block/sda/sda3: ASCII text
[11:30:03] /dev/.udev/db//block/sda/sda1: ASCII text
[11:30:03] /dev/.udev/db//block/sdb/sdb1: ASCII text
[11:30:03] /dev/.udev/db//block/sda: ASCII text
[11:30:03] /dev/.udev/db//block/sdb: ASCII text
[11:30:03] /dev/.udev/db//block/ram0: ASCII text
[11:30:03] /dev/.udev/db//block/ram1: ASCII text
[11:30:03] /dev/.udev/db//class/mem/null: ASCII text
[11:30:03] /dev/.udev/uevent_seqnum: ASCII text
[11:30:04] Checking for hidden files and directories [ Warning ]
[11:30:04] Warning: Hidden directory found: /dev/.udev
[11:30:04] Warning: Hidden file found: /etc/.php.ini.swo: Vim swap file, version 7.1
[11:30:04] Warning: Hidden file found: /etc/.proftpd.conf.swp: Vim swap file, version 7.1
[11:30:04] Warning: Hidden file found: /usr/share/man/man1/..1.gz: gzip compressed data, from Unix, max compression



[11:30:10] Checking version of OpenSSL [ Warning ]
[11:30:10] Warning: Application 'openssl', version '0.9.8b', is out of date, and possibly a security risk.
[11:30:10] Checking version of Apache [ Warning ]
[11:30:10] Warning: Application 'httpd', version '2.2.8', is out of date, and possibly a security risk.
[11:30:10] Checking version of OpenSSL [ Warning ]
[11:30:10] Warning: Application 'openssl', version '0.9.8b', is out of date, and possibly a security risk.
[11:30:10] Checking version of PHP [ Warning ]
[11:30:11] Warning: Application 'php', version '5.2.6', is out of date, and possibly a security risk.
[11:30:11] Checking version of OpenSSH [ Warning ]
[11:30:11] Warning: Application 'sshd', version '5.5p1', is out of date, and possibly a security risk.

missed a few...


[11:26:41] /usr/bin/chattr [ Warning ]
[11:26:41] Warning: File '/usr/bin/chattr' has the immutable-bit set.

[11:26:43] /usr/bin/GET
[11:26:43] Warning: The command '/usr/bin/GET' has been replaced by a script: /usr/bin/GET: perl script text executable

Then, in the situation that the OpenSSH daemon actually is compromised, pass phrases or passwords may be leeched.


If unsure you're supposed to post the output.


I told you that certain software should be installed before suspected breach of security, not after. I also asked you a few specific questions and asked you to report back. So get on it. (BTW RKH output doesn't convey much so if you must, but only after you answered the other questions, feel free to attach /var/log/rkhunter.log.)

Allow me to reiterate that I am indeed a beginner and I do appreciate the help. What I posted earlier (includes [hh:mm:ss]) is indeed from the rkhunter.log. I didn't post the results of the rpm command due to it being lengthy. Here is a link to the command output.

http://ptcs.us/rpm.txt

From 'man rpm' under "verify options: This doesn't spell much good:
BTW I checked 5 or 6 applications from your /usr/local/psa/var/cgitory/ and those were completely out of date (and with that I mean major versions or even years behind). It would be really bad if those were in use right now.

I did note that there were applications out of date and I would need to upgrade. Our cms, Plesk is indeed out of date, but the only way to to upgrade from our current version would be to switch servers from Fedora Red Hat 7 to Centos. I am just attempting to secure what we have for the time being.

Should I attempt to update all application possible at this point?

Should I attempt removing openssh and reinstalling?

Forgive me for all the questions, but the company I work for doesn't have a system administrator. I would like to lock down the server as best as I can. Any advice on how to proceed would be greatly appreciated.

Thanks again, unSpawn!

There is no "Fedora Red Hat 7": there is Red Hat Linux 7 from 2000 and there is Fedora 7 from 2007 and both are way out of date. "Just attempting to secure what we have for the time being", updating software, re-installing software will not make the machine secure, ergo would be an exercise in futility. How to proceed?
Two-pronged approach really: list what software you really need, set up a new machine, install a current distribution release with only the necessary packages, harden it (create a new thread for that please) AND investigate the old machine to find out the extent of the damages: check all users shell history, look in /home, /tmp, /var/tmp, your docroot and other regular places for anomalous files (binaries, tarballs, files owned by root or the web server, etc, etc) and check your 'lastlog; last -wai' and run all log files in /var/log through Logwatch for clues on another machine. Make off-site backups and mark them as compromised so you don't restore them later on.


Then either the company you work for should hire one or seek a solution that doesn't damage its brand image and doesn't expose other Internet users to threats. Unmaintained Linux installations contribute considerably to spam, malware and botnet problems around the world. Responsible netizens should not be part of that.
Linux may be free to use but using Linux should not be free of responsibilities.

1 members found this post helpful.

Sorry, but when viewing specs on godaddy the OS is stated to be Red Hat Fedora Core 7. I did not expect the re-installation of software to make the system more secure. I only thought that it would maybe get rid of the issue with the ssh server. I have mentioned upgrading our server to CentOS (godaddy will set up). My only concern was that when using the backup manager provided by Plesk it states "Server configuration and content." I will open a new thread about this as I am unsure if using the backup would pull unwanted data to the new server.

You can find sites to rent out your systems administration work on the cheap, to rated professionals. This sounds like a quick job.