Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
One of our servers was subjected to a crack attempt that tried to grab the /etc/passwd file. The file does not appear to have been touched due to the timestamp on the file not being of a recent date. However, just to make sure, I wanted to know if there are other tests that can be done to verify this.
One thought that I had was the following: The server is regularly backed up, and I could do a restore of an older version of the passwd file to a temporary directory. Once there, the diff command could be used to compare the two files.
You could compare but with the timestamps more than likely nothing was modified. However, the timestamps won't tell you if it was read successfully by the request which would give the cracker the list of user accounts set up on the server. The /etc/passwd file is world readable by default so it could be read by any other user that attempted to get it. Wikipedia has some info on this type of attack: http://en.wikipedia.org/wiki/Directory_traversal_attack
You can do some searching on how to prevent this but its usually only prevented with input sanitation done on the web server level.
One of our servers was subjected to a crack attempt that tried to grab the /etc/passwd file.
How exactly did you determine this? Wasn't it only one line in a long line of what appears to be web stack application probes?
Being as verbose as possible would be appreciated.
The incident has been classified by our support engineers:
Alarm Source: Malicious
Sub Category: Exploits
Actions: No Action
Classification Details:
Malicious packet triggered on Sig-ID 3201/1.
Alarm triggered on Unix Password File Access Attempt traffic from the external host at <ip address> to the external host at <ip address>.
These alarms triggers when any cgi-bin script attempts to retrieve password files on various operating systems. Such as the /etc/passwd. This may indicate an attempt to illegally access system resources, in particular the /etc/passwd file. This may be the prelude to a more serious attack. No valid reason to access these files via this mechanism exists. Hosts that attempt to access the these files, especially from outside your network, should be shunned. The internal host should also be checked for possible compromise.
I am going through the system and web server log files to determine if a successful connection was made, and the file in question was accessed from the remote system.
You have the event date and time. Look at your Apache error and access logs for a query that contains passwd and, or shadow, probably with a bunch of ../../ in it. Normally, a user should not be able to browse outside of the document path, but it is prudent to see if access to this file were gained.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.