hello all !
everyone know an attacker can hack local when them have one account on our server ! attackers user remview to browse or tool cgi-telnet to get etc/passwd or etc/shadowpasswd....and then deface websites very easy.
so, my question: how to fix server to disablen remview and cgi-telnet to protect again hackers ?:confused: :confused:

get rid of those cgi scripts or setup a chroot jail.

Erm,

They should not be able to read /etc/shadow, if they can, then the server isn't correctly configured.

The only realistic way to prevent these types of CGI scripts causing problems is to set your *nix file/directory permissions correctly.

Searching for a particular script is a complete waste of time, and trying to chroot and account for CGI purposes is of some protection, but can often be broken out of. Nothing replaces good old basic file permissions.

what and where exactly need to be putted for "They should not be able to read /etc/shadow" ?

could you please tell this?

what he's saying is /etc/shadow is the system file that holds all your machines passwords. It therefore should only be able to be read and written to by the super user (root), and noone else should be able to get anywhere near it. The default for every linux distribution is this level of security though.

Back in the day, system passwords were stored in the world (everyone) readable file /etc/passwd, so it was just a case of getting something to read it, whether a cgi script or logging in via ftp and copying the file, then using an offline cracker to steal the passwords..

yes, I understood this :)

what should be performed to not allow user to read file?

because he can read file with root:root and 644 permissions...

What Slidey said ;)

Also, the file permissions on /etc/shadow should be 600 and the ownership of root.root. Anything else is wrong.

maybe it is OK for /etc/shadow

but there are many files that not necessary to customer to view but they need to be 644 at least...

phpsuexec is the best for this ! i'v used it over a year and feel very safe .

phpsuexec do not allow your clients to modify files but it is not prevent to directory listing and file content viewing.

644 permissions is normal for php suexec - but it is also allow to read files.

no , i using phpsuexec and my customer can chmod php file is 600 and directory is 701 . So no one can read anything under directory or file content

yes, they can chmod but when they upload files into account that files have 644 - by default.

also you have much files with 644 under the /etc dir.
like password files :)

I'm not sure I can change permisions for them w/o troubles...

the important file is /etc/shadow. that should be 600. if it isnt, change it that way, then change every password on your system.

/etc/passwd *should* be 644. it contains things like userids and homedirs

Reading /etc/passwd is not a security risk unless you are not running shadow passwords which all linux distributions use nowadays.

Originally posted by blackmoont
phpsuexec is the best for this ! i'v used it over a year and feel very safe .

cgi-telnet as its name suggest is CGI and not PHP. End of the day, security on the server is all round. Your suggestion won't help a bit in this scenario.

At the end of the day, if your server can be compromised by cgi-telnet for example, even if you block it, it means that they are many other avenues that your server can be compromised.

If remview is the script that I know about then, it's a PHP script.
To prevent users from browsing the file system with remview, you need to enable safe mode in php.ini and use open_basedir configuration option on a per virtualhost basis. This will allow them use php scripts only within their home directory or public_html directory (depending on what you set it to).

As for cgitelnet script, which is a CGI script, use mod_security apache module, it lets you filter out access to certain directories and also has an audit file that logs all bad access attempts as well as other things and you can look though it to check if users on your server behave.

Greetings:

We've found mod_security from http://www.modsecurity.org/ to work wonders in terms of preventing these types of programs from having access to areas of concern on a server.

Thank you.

you may need to look at admin0's website

specific URL to this issue is: < Removed. > < Specific URL to Forum Guidelines.http://www.webhostingtalk.com/misc.php?s=&action=forum-rules >