Yup. It seems that ntop is somehow seeing the http:// as part of the
request - normally I thought that gets stripped off and only the uri portion
(e.g. tssyd:3000/ is what is seen by checkURLsecurity.
In http.c, there's a setting for HTTP_DEBUG - enable it in globals-define.h
and look for lines like this:
Jan 5 07:11:14 tigger ntop[10168]: HTTP/I18N_DEBUG: Requested URL =
'/functions.js', length = -1 [MSGID0630432]
Jan 5 07:11:14 tigger ntop[10168]: HTTP/I18N_DEBUG: User-Agent =
'Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)'
[MSGID1022638]
Jan 5 07:11:14 tigger ntop[10168]: I18N_DEBUG: Accept-Language =
'en-us,en;q=0.5' [MSGID8772014]
07:11:39 tigger [Linux] user=ntop pwd=~ $
in your log - we need to figure out how the request is being packaged into
the tunnel... and what ntop is seeing.
I've tested my Linux system and I'm NOT seeing the http:// in the tunneled
request, both -w 3000 and -W 3001. But I'm using a 3rd party ssh, not
openssh (which version, BTW, is installed on the local host? And what
version OS, etc. is that system?)
There's also a DEBUG line around 265 (which you should manually enable by
just deleting the #ifdef and #endif lines):
#ifdef DEBUG
traceEvent(CONST_TRACE_INFO, "DEBUG: read HTTP %s line: %s [%d]",
(numLine>1) ? "header" : "request", lineStr, idxChar);
#endif
Which reports the actual stuff being pulled from the http request headers.
A cheesy fix:
} else if(numLine == 1) {
>>> if(strncmp(lineStr, "http://";, 7) == 0) { memset(&lineStr, ' ',
7); }
>>> if(strncmp(lineStr, "https://";, 8) == 0) { memset(&lineStr, ' ',
8); }
strncpy(httpRequestedURL, lineStr,
sizeof(httpRequestedURL)-1)[sizeof(httpRequestedURL)-1] =
'\0';
might work...
-----Burton
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
> Of Stanley Hopcroft
> Sent: Sunday, January 04, 2004 8:41 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Ntop-dev] PR: Can't access 2.2.98 web server via forwarded
> SSH connection.
>
>
> Dear Sir,
>
> On Sun, Jan 04, 2004 at 06:02:39PM -0800, Burton Strauss wrote:
> > Run it with --trace-level 4 (noisy) so you see the actual
> reject message from urlSecurity() in http.c (there's about 4
> things that cause code=2)...
> >
> > -----Burton
>
>
> Looks like //
>
<snip />
> Jan 5 13:39:30 tssyd ntop[73331]: URL security(2): Found // in
> URL...rejecting request
> Jan 5 13:39:30 tssyd ntop[73331]: **ERROR** URL security:
> 'http://tssyd:3000/' rejected (code=2)(client=192.168.102.230)
> Jan 5 13:39:34 tssyd ntop[73331]: **ERROR** Rejected request from
> address 192.168.102.230 (it previously sent ntop a bad request)
> Jan 5 13:39:40 tssyd ntop[73331]: **ERROR** Rejected request from
> address 192.168.102.230 (it previously sent ntop a bad request)
> Jan 5 13:39:46 tssyd ntop[73331]: SECURITY: Loading items table
> tssyd>
<snip />
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
