httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "KAN NAN" <>
Subject Re: [users@httpd] Request !
Date Thu, 04 Sep 2003 08:13:20 GMT
<html><div style='background-color:'><DIV>
<P>Thanks a lot Mr.Brian......&nbsp;</P>
<P>I accept your points. As far as ports are concerned and it is open to internet world,
ofcourse it should accept the connection. But to add on the point, We face internal server
error mostly from this ip-addresses, Will there be any problem or misconfiguration at JServ
<P>This is the log entry found at JServ log files, please note that all this error occured
at the same time.</P>
<P>[02/09/2003 08:59:35:604 BST] AJP Protocol Error: Connection
reset by peer: JVM_recv in socket input stream read<BR>[02/09/2003 08:59:35:604 BST] Connection reset by peer: socket write error<BR>&nbsp;at Method)<BR>&nbsp;at,
Compiled Code)<BR>&nbsp;at,
Compiled Code)<BR>&nbsp;at,
Compiled Code)<BR>&nbsp;at org.apache.jserv.JServConnection.sendError(<BR>&nbsp;at, Compiled Code)<BR>&nbsp;at, Compiled Code)<BR>[02/09/2003 08:59:35:619 BST] AJP
Protocol Error: Stream closed prematurely<BR></P>
<P>This may could have caused the Internal server error, not sure....<BR>waiting
for your reply...<BR>thanks,<BR>-kannan</P>
<DIV></DIV>&gt;From: Brian Dessent <BRIAN@DESSENT.NET>
<DIV></DIV>&gt;Subject: Re: [users@httpd] Request ! 
<DIV></DIV>&gt;Date: Wed, 03 Sep 2003 17:04:35 -0700 
<DIV></DIV>&gt;KAN NAN wrote: 
<DIV></DIV>&gt; &gt; 
<DIV></DIV>&gt; &gt; Dear friends, 
<DIV></DIV>&gt; &gt; 
<DIV></DIV>&gt; &gt; I accept the points given by Mr. Garriss and Mr.
<DIV></DIV>&gt; &gt; See, these are the log entries from Apache. It is
really very 
<DIV></DIV>&gt; &gt; difficult to identify what they were trying to do.
The reason why I 
<DIV></DIV>&gt; &gt; was quite sure that they were using telnet is, previously
our system 
<DIV></DIV>&gt; &gt; suffered, at that time I could see that these people
were using 
<DIV></DIV>&gt; &gt; CONNECT, so in my apache
config file, I 
<DIV></DIV>&gt; &gt; blocked all kind of CONNECT request. So, it solved
me. But this time, 
<DIV></DIV>&gt; &gt; just have a look at the log entries: 
<DIV></DIV>&gt; &gt; 
<DIV></DIV>&gt; &gt; - - [02/Sep/2003:08:59:31 +0100] "GET
/ HTTP/1.1" 400 380 
<DIV></DIV>&gt; &gt; - - [02/Sep/2003:08:59:43 +0100] "POST
/ HTTP/1.1" 500 
<DIV></DIV>&gt; &gt; 604 
<DIV></DIV>&gt;First of all, please understand that a connection is a connection
<DIV></DIV>&gt;they all look the same to Apache. The program servicing requests
<DIV></DIV>&gt;that port (Apache) has no -inherent- way to determine whether
<DIV></DIV>&gt;incoming connection is from someone using Telnet, wget, curl,
a perl 
<DIV></DIV>&gt;module such as LWP::Simple, a browser such as Internet Explorer,
or any 
<DIV></DIV>&gt;other of a large number of programs out there. The only thing
<DIV></DIV>&gt;Apache has to go by is what the other end transmitts, there's
no way to 
<DIV></DIV>&gt;close off a port from one program and not another. Yes, you
can look at 
<DIV></DIV>&gt;the User-Agent field but that's hardly authoritative, and by
that point 
<DIV></DIV>&gt;the request has already been sent, i.e. it's not a form of
<DIV></DIV>&gt;Second, if you put a server on the public internet you should
expect to 
<DIV></DIV>&gt;get some bad queries, it's just how the world works. Most of
the time, 
<DIV></DIV>&gt;the are from other infected machines (such as Code Red and
Nimda) but 
<DIV></DIV>&gt;they can also be from random people telnetting into port 80
and typing 
<DIV></DIV>&gt;whatever they want. However, Apache (and any other web server)
has been 
<DIV></DIV>&gt;specifically designed with this in mind, and bad queries should
<DIV></DIV>&gt;affect operation in the least. 
<DIV></DIV>&gt;The above log entries are invalid queries most likely because
they did 
<DIV></DIV>&gt;not include the "Host:" header that HTTP 1.1 requires. They
would not 
<DIV></DIV>&gt;have affected operation of your server in the least, as the
<DIV></DIV>&gt;simply sends an error message and continues along with its
<DIV></DIV>&gt;There are only three circumstances where I could imagine that
bad or 
<DIV></DIV>&gt;malformed requests would be a serious issue: 
<DIV></DIV>&gt;1. If you are running a particularly old version of Apache
that has a 
<DIV></DIV>&gt;vulnerability and someone is using it. If this is the case
you should 
<DIV></DIV>&gt;upgrade to a recent version. 
<DIV></DIV>&gt;2. The person on the other end is swamping you with millions
<DIV></DIV>&gt;requests. IN this case you should block that IP address or
subnet in 
<DIV></DIV>&gt;the firewall or gateway router. 
<DIV></DIV>&gt;3. There's some new vulnerability not yet known to the Apache
<DIV></DIV>&gt;and security research community. This is highly unlikely, and
if it 
<DIV></DIV>&gt;turned out to be the case there would most likely be a great
deal of 
<DIV></DIV>&gt;noise being made about it by someone... i.e. it's not the kind
of thing 
<DIV></DIV>&gt;you just stumble upon. 
<DIV></DIV>&gt;Now you said that these bad queries are affecting your operation

<DIV></DIV>&gt;somehow. The real question is, "How is that exactly?" If you
mean that 
<DIV></DIV>&gt;you're losing sleep over a few bad connections in a log file,
then you 
<DIV></DIV>&gt;just need to relax (assuming your system is up to date of course.)
<DIV></DIV>&gt;there's any sort of measurable performance impact from the
<DIV></DIV>&gt;bad request, then either something is configured wrong, or
these queries 
<DIV></DIV>&gt;are more than infrequent and the source should be blocked.


<DIV></DIV>&gt;The official User-To-User support forum of the Apache HTTP
Server Project. 
<DIV></DIV>&gt;See <URL:http: userslist.html>for more
<DIV></DIV>&gt;To unsubscribe, e-mail:

<DIV></DIV>&gt; " from the digest:

<DIV></DIV>&gt;For additional commands, e-mail:

<DIV></DIV></URL:http:></div><br clear=all><hr>Meet Virgo.
Fall in love. <a href="">With perfection!</a>

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message