AntiOnline's Intrusion Logs

I was just checking out the intrusion logs on this site and i was wondering, what exactly are http shells? It seem that every intrusion attempt says that it was an http shell. So this has me wondering if some of the "attacks" arent false alarms. Once again i dont have any idea because i dont know what http shells are.

I tried to search google for http shells but all i came up with are *nix shells. Would someone please tell me what is trying to be done when i see http shells in the intrusion logs?

thanks.

http_shells are like a DoS attack they are directed at port 80 to slow down the site trying to bring it to a halt

It's just a lame ass DOS attack aimed at port 80(http)

ooohhh i see, hmmm seems like seeing all the failed attempts in the logs that they wouldnt even try it anymore.

Ummmmm....http_shells means that someone was trying to access a shell through http (sh, csh, tcsh, bash, ksh); however, this signature is frequently a false positive (as it detects those strings in any packet).

Here is the official signature description from RealSecure (which if you look it says is where he is getting those events):

Quote:

RealSecure Network Sensor: This signature detects attempts to get shells to execute commands. This signature detects any calls to shell interpreters at any location (not only the cgi-bin directory) within or outside the Web server.

This signature was replaced by HTTP_Shells_Bash, HTTP_Shells_C, HTTP_Shells_Perl, HTTP_Shells_Perl_Exe, HTTP_Shells_Rksh, HTTP_Shells_Sh, HTTP_Shells_Tcsh, and HTTP_Shells_Ksh.

False Positives:
RealSecure Network Sensor: A false positive is possible for Web pages that that have the same name as shell interpreters. Even in the event of a false positive, it is still considered bad security practice to put shell interpreters (such as sh, csh, etc.) in the cgi-bin directory. A false positive is also possible, though unlikely, for a Web page that has the same name as an obscure shell interpreter (for example, "python").

Vulnerability description
A common Web server misconfiguration is to put shell interpreters (such as sh, csh, etc.) in the cgi-bin directory. Also, some early Web server documentation stated that CGI script interpreters (such as Perl, Tcl, etc.) should be placed in the cgi-bin directory.

Placement of shell interpreters and CGI script interpreters in the cgi-bin directory could allow a remote attacker to execute arbitrary commands through the interpreters. By sending specially formatted HTTP requests, an attacker could cause these shells to execute arbitrary commands. For example, an attacker could send a specially formatted HTTP request that would cause password files to be emailed.

How to remove this vulnerability
Determine if any cgi-bin programs rely on shell interpreter access. If they do, move the shell interpreter outside the www root, and modify the cgi-bin programs to look for the shell interpreter in the new location. If no programs use the shell interpreter, remove it from the cgi-bin directory.

Evaluate locally authored CGI executables to ensure that they do not pass unvalidated user-supplied data to system commands.

Enjoy,

Nebulus