[NBLUG/talk] How to read logwatch & httpd access_log

Ron Wickersham rjw at alembic.com
Sun Jan 23 23:09:05 PST 2005


On Sun, 23 Jan 2005, Dave Sisley wrote:

> > > > access_log:81.219.11.226 - - [09/Jan/2005:19:04:28 -0800] "CONNECT 1.3.3.7:1337 HTTP/1.0" 200 12551 "-" "-"
> > > > access_log.1:216.102.227.194 - - [06/Jan/2005:20:50:47 -0800] "CONNECT 1.3.3.7:1337 HTTP/1.0" 200 12550 "-" "-"
> > > > access_log.3:216.240.146.76 - - [20/Dec/2004:17:09:02 -0800] "CONNECT 1.3.3.7:1337 HTTP/1.0" 200 12596 "-" "-"

---snip---

> > so apparently you're actually delivering the requested material.  otherwise
> > you'd see the same request coming in but send back an error message and
> > not a 200 header type.
>
> This is what worries me.  What's the 'requested material'?
>
> I have taken Augie's advice and commented out the mod_proxy 'load
> module' lines in my httpd.conf file.  I've also not seen any further
> '1337' activity in my access_log files since my original post.
>
> FWIW, I'm running Apache 2.0.51, so I don't think I'm susceptible to
> the hack Augie cited.
>
> My problem is that I don't understand the data logwatch is sending
> me.  Their website is not very helpful (documentation consists of a
> reprint of the logwatch manpage).
>
> If I can get some time (I just started a new job), I will look for
> info on how to read my access_log files.
>
> In the meantime, I (and perhaps others on the list) would appreciate
> tips on how to keep a better eye on my server.

i don't know anything about logwatch, but asssume that it reads each
line of a log and attempts to select "interesting" lines and e-mail
them to you.

so assuming that you're not asking about configuring logwatch, but
interested in what the apache log file line that was selected...

access_log:	(this line suggests that it refers to the apache transfer
		log which traditionally is named access_log)   the
		transfer log is a space-delimited line-oriented file where
		each line records a request sent to the apache server

81.219.11.226	(this is the ip address in the header of the incoming
		packet that tells you where the request originated -
		dig -x 81.219.11.225 will do a reverse dns lookup
		and in the answer:
226.11.219.81.in-addr.arpa. 86343 IN    CNAME   226.224/28.11.219.81.in-addr.arpa.
226.224/28.11.219.81.in-addr.arpa. 86343 IN PTR raks03.raks.pl.

		(which tells us that 226.11.219.82.in-addr.arpa's pointer
		is not directly provided. it's one of a netblock of 16
		addresses starting at 81.219.11.224 and it's delegated
		with the CIDR hack to 226.224/28.11.219.81.in-addr.arpa.
		the real pointer says it's a machine named raks03.raks.pl.

-		this second item is blank (and is usually blank) unless
		the sender offered his identity.

-		the third item is blank (and is usually blank) unless you
		have authentication turned on (so you have to give your
		user name and password to access pages) and in that case
		it would contain the user name that was authenticated.

[09/Jan/2005:19:04:28 -0800]	the fourth thing is the time of the request
		and has to be contained in brackets since it contains a
		space for the offset from UTC

"CONNECT 1.3.3.7:1337 HTTP/1.0"  the fifth thing is the actual request
		sent in.  the usual request is a GET to get an html file
		or a picture or whatever.   if you've filled in a form,
		a POST request will say that the info you put in the form
		is attached.  but in this case it's a CONNECT which instructs
		apache to itself connect to port 1337 on a server at 1.3.3.7
		and then give back to the requesting host what you found
		on server 1.3.3.7.   well since that's not a routable address
		what they wanted to get was how you handled the CONNECT.
		if your apache instance wasn't configured to proxy it would
		return a status code of 400 saying it can't do your request.
		but in this case it returned a message that (i'm guessing)
		said "i tried to connect for you but was't able to get a
		response".

		this part of the log entry has to be in double quotes since
		it contains spaces.  the first part was the type of request,
		the second, the information requested, and the third part
		the protocol, in this case HTTP version 1.0.

200		the sixth section is the response code, in this case a
		200 which says, i understood what you asked for and
		believe that i'm returning you the information you requested.

12551		the seventh section is the number of bytes returned and its
		the length of what you got that concerns me.  i'll show you
		later what i get when apache can't do a CONNECT.

"-"		this eighth section would contain the Referrer info, so
		if i got here by clicking on a link, you'd see the URL
		of the page containing the link.

"-"		and finally the browser id (or robot id) which tells you
		the browser version, operating system and anything else
		the broswer designed decided to send.

this is the organization of a line in the access_log of an apache (or
even the "unpatched" httpd server, since the log format hasn't changed)
server using the combined log format.   originally there was a separate
referrer log, but early on people got the idea that it was easier to have
the referrer in the same line as the request.   these log formats are
changable by the configuration file, but most servers just run with this
format and log analyzers expect logs in this format.

####

i made a request to a web server here.   by using telnet you can send
anything you want to type, so i telnet to port 80 (where apache is listening):

telnet www.alembic.com 80
Trying 66.182.11.242...
Connected to alembic.com.
Escape character is '^]'.

	the server has answered and is waiting for my instructions

CONNECT 192.82.19.253:25 HTTP/1.0

	this is what i typed to see what i would get with a CONNECT request.
	the only hard thing about using apache this way is that you are
	not allowed to make any typing mistakes at all, so it doesn't
	observe "delete key" since apache expects a program to contact it
	not a human typing.     and after you type the line, you have
	to type two returns (some requests take more than one line, so
	the end of the request is signalled by a blank line).

HTTP/1.1 405 Method Not Allowed
Date: Mon, 24 Jan 2005 06:27:58 GMT
Server: Apache/1.3.9 (Unix) mod_perl/1.21
Allow: GET, HEAD, OPTIONS, TRACE
Connection: close
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>405 Method Not Allowed</TITLE>
</HEAD><BODY>
<H1>Method Not Allowed</H1>
The requested method CONNECT is not allowed for the URL /index.html.<P>
<HR>
<ADDRESS>Apache/1.3.9 Server at alembic.com Port 80</ADDRESS>
</BODY></HTML>
Connection to alembic.com closed by foreign host.

	this whole block spewed out, where you see the beginning part
	where the first 6 lines are intended for the browser to read,
	followed by a blank line.    then it sends the html marked up
	message to be displayed to the reader.    the final line
	is a message from the local telnet client.

now let's look on the apache machine for the log file of this request:

batz.alembic.com - - [23/Jan/2005:22:30:15 -0800] "CONNECT 192.82.19.253:25 HTTP/1.0" 405 298 "-" "-"

you can see that it has the information expected, with my request, but
the status code is not 200, it's 405 and only 298 bytes were returned.

it appears that your machine was doing something that made it return an
OK 200 status code and a big block of data.

-ron

--
/~\  The ASCII Ribbon Campaign
\ /    No HTML/RTF in email
 X     No Word docs in email
/ \  Respect for open standards





More information about the talk mailing list