I believe had something working earlier today albeit briefly but I was feeling 
so twitchy that I couldn't concretely verify that spammers were not using the 
proxy inappropriately that I did not leave it up until I could pay more 
attention to it later.

So I get home late this afternoon and start up the system again although this 
time, I'm not seeing any messages in the error log so I try accessing from an 
external machine.  I get a 503 message.  I figure everybody's getting a 503 
message.  And I've been trying different things in the configuration but
nothing 
works.  It seems like this configuration is so simple there shouldn't be a
problem.

I make a listen statement use the IP address of the system it is running on.  I

follow the instructions in the examples for the rest of the group statement. 
I'm puzzled.  What clue am I missing?

ListenHTTP 192.168.25.1,80

UrlGroup ".*"
HeadRequire Host "http://www.tbtf.com.*"
BackEnd 192.168.25.22,80,1
EndGroup


it would have helped me a lot to have a debug mode which would tell me 
everything it sees and everything responds with.  Please consider adding a 
debugger to the system in the future.

many thanks

---eric

Hello!

Am Freitag, 19. September 2003 01:05 schrieb Eric S. Johansson:
> ListenHTTP 192.168.25.1,80
>
> UrlGroup ".*"
> HeadRequire Host "http://www.tbtf.com.*"
> BackEnd 192.168.25.22,80,1
> EndGroup

The HeadRequire statement seems to be wrong. Have a look at the RFC:

  http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23


Andi
-- 
-> Andreas Roedl            -> IT Director
-> NATIVE INSTRUMENTS GmbH  -> andreas.roedl(at)native-instruments.de
-> Schlesische Strasse 28   -> http://www.native-instruments.de/
-> D-10997 Berlin           -> Tel. +49-30-61 10 35-430
-> Germany                  -> Fax  +49-30-61 10 35-35

On Friday 19 September 2003 01:05, you wrote:
> I believe had something working earlier today albeit briefly but I was
> feeling so twitchy that I couldn't concretely verify that spammers were not
> using the proxy inappropriately that I did not leave it up until I could
> pay more attention to it later.
>
> So I get home late this afternoon and start up the system again although
> this time, I'm not seeing any messages in the error log so I try accessing
> from an external machine.  I get a 503 message.  I figure everybody's
> getting a 503 message.  And I've been trying different things in the
> configuration but nothing works.  It seems like this configuration is so
> simple there shouldn't be a problem.
>
> I make a listen statement use the IP address of the system it is running
> on.  I follow the instructions in the examples for the rest of the group
> statement. I'm puzzled.  What clue am I missing?
>
> ListenHTTP 192.168.25.1,80

Are you sure about that? Is it accessed ONLY from the internal network?

> UrlGroup ".*"
> HeadRequire Host "http://www.tbtf.com.*"

You probably mean:

HeadRequire Host ".*www.tbtf.com.*"

The 'http://' is (normally) not sent by the browser and thus the whole fails 
to match.

> BackEnd 192.168.25.22,80,1
> EndGroup
>
>
> it would have helped me a lot to have a debug mode which would tell me
> everything it sees and everything responds with.  Please consider adding a
> debugger to the system in the future.

Your best debugger is a packet sniffer. For simple cases we use tcpwatch (it 
is good with understanding and displaying HTTP requests). If you really want 
the full nitty-gritty, inclusive of details on the TCP setup, have a look at 
something like ettercap.

In any case we saw no need to add the complexity of a full debug output to 
Pound (after all it could introduce problems by itself) when the same 
information is easily available via existing tools.

> many thanks
>
> ---eric

You're welcome (or velcome, as they say in Havaii).
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

Andreas Roedl wrote:

> Hello!
> 
> Am Freitag, 19. September 2003 01:05 schrieb Eric S. Johansson:
> 
>>ListenHTTP 192.168.25.1,80
>>
>>UrlGroup ".*"
>>HeadRequire Host "http://www.tbtf.com.*"
>>BackEnd 192.168.25.22,80,1
>>EndGroup
> 
> 
> The HeadRequire statement seems to be wrong. Have a look at the RFC:
> 
>   http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23

interesting.  I see what you mean.  There isn't a http:// in the host 
definition

but if you look in the readme, you'll find:

     UrlGroup    ".*"
     HeadRequire Host    "http://www.server0.com.*"
     BackEnd     192.168.0.10
     EndGroup

and that is what I was following.  Then in the following example, you 
find the form that works. (this is also true on the web page).  I 
stripped out the http:// and amazingly it started working.

Thank you for the pointer.

if I wanted to do something like HeadDeny Post .*:25 to explicitly 
filter out any of the spammer proxy relay attempts, is it necessary, and 
is it a good idea?

---eric




---eric

Robert Segall wrote:

> On Friday 19 September 2003 01:05, you wrote:
> 
>>I believe had something working earlier today albeit briefly but I was
>>feeling so twitchy that I couldn't concretely verify that spammers were not
>>using the proxy inappropriately that I did not leave it up until I could
>>pay more attention to it later.
>>
>>So I get home late this afternoon and start up the system again although
>>this time, I'm not seeing any messages in the error log so I try accessing
>>from an external machine.  I get a 503 message.  I figure everybody's
>>getting a 503 message.  And I've been trying different things in the
>>configuration but nothing works.  It seems like this configuration is so
>>simple there shouldn't be a problem.
>>
>>I make a listen statement use the IP address of the system it is running
>>on.  I follow the instructions in the examples for the rest of the group
>>statement. I'm puzzled.  What clue am I missing?
>>
>>ListenHTTP 192.168.25.1,80
> 
> 
> Are you sure about that? Is it accessed ONLY from the internal network?

actually yes.  It is sitting behind an address translation firewall.  So 
if I told Pound to listen to the external interface of the firewall, we 
wouldn't get very far.  ;-)

this is one of the contexts in which name based virtual domain request 
routing is extremely useful.  If you're sitting behind a single IP 
address and you want to send your HTTP requests to multiple machines, 
this is the only way to do it.



>>UrlGroup ".*"
>>HeadRequire Host "http://www.tbtf.com.*"
> 
> 
> You probably mean:
> 
> HeadRequire Host ".*www.tbtf.com.*"
> 
> The 'http://' is (normally) not sent by the browser and thus the whole fails 
> to match.
> 

understood now.  Like I said in the previous e-mail the documentation is 
wrong in one spot.  It's probably historical. I've made that kind of 
mistake at least once in my life and probably in the past few months.  I 
have a highly evolving antispam system (camram) under development and it 
really gets old reworking the install notes and README to keep them 
accurate.  :-)

> Your best debugger is a packet sniffer. For simple cases we use tcpwatch (it 
> is good with understanding and displaying HTTP requests). If you really want 
> the full nitty-gritty, inclusive of details on the TCP setup, have a look at 
> something like ettercap.

I primarily want a higher level view of the protocol when starting 
initial debugging.  I had been making do with tcpdump and iptraf but 
they weren't really what I need.  If I have a GUI available, I'll use 
ethereal but I'm still try to find the time to puzzle out the filter 
rules.  I'll take a look at the tools you refer to and see if there any 
better.

> In any case we saw no need to add the complexity of a full debug output to 
> Pound (after all it could introduce problems by itself) when the same 
> information is easily available via existing tools.

fair enough.

---eric

On Friday 19 September 2003 14:00, you wrote:
> if I wanted to do something like HeadDeny Post .*:25 to explicitly
> filter out any of the spammer proxy relay attempts, is it necessary, and
> is it a good idea?

I am not aware of any Post header - is that part of some new RFC?
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

On Friday 19 September 2003 14:09, you wrote:
> >>UrlGroup ".*"
> >>HeadRequire Host "http://www.tbtf.com.*"
> >
> > You probably mean:
> >
> > HeadRequire Host ".*www.tbtf.com.*"
> >
> > The 'http://' is (normally) not sent by the browser and thus the whole
> > fails to match.
>
> understood now.  Like I said in the previous e-mail the documentation is
> wrong in one spot.  It's probably historical. I've made that kind of
> mistake at least once in my life and probably in the past few months.  I
> have a highly evolving antispam system (camram) under development and it
> really gets old reworking the install notes and README to keep them
> accurate.  :-)

Thanks - it has been corrected now (README, pound.8 and the web page).
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

Robert Segall explained:
> On Friday 19 September 2003 14:00, you wrote:
> 
>>if I wanted to do something like HeadDeny Post .*:25 to explicitly
>>filter out any of the spammer proxy relay attempts, is it necessary, and
>>is it a good idea?
> 
> 
> I am not aware of any Post header - is that part of some new RFC?

I'm taking shortcuts.  Somebody should take a way the send button until I am 
fully awake.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5

post is one of the request headers and actually, I would probably block+log on 
any of them going to Port 25 so I can harvest information to feed into my 
firewall to terminate the connection with prejudice.

another option would be to do tarpitting which would be to accept the 
connection, and then just sit on it and wait just slightly less than standard 
timeout values and get the next line.  And so on and so forth.  you drag 
everything out in glacial slowness but not so slow that they go away.  You just

slow them down.

Now I am fully cognizant this is definitely out of the scope of pound but you 
must admit it is a nice thing to do to spammer resources.

---eric

On Friday 19 September 2003 14:38, you wrote:
> post is one of the request headers and actually, I would probably block+log
> on any of them going to Port 25 so I can harvest information to feed into
> my firewall to terminate the connection with prejudice.
>
> another option would be to do tarpitting which would be to accept the
> connection, and then just sit on it and wait just slightly less than
> standard timeout values and get the next line.  And so on and so forth. 
> you drag everything out in glacial slowness but not so slow that they go
> away.  You just slow them down.
>
> Now I am fully cognizant this is definitely out of the scope of pound but
> you must admit it is a nice thing to do to spammer resources.
>
> ---eric

I suspect you mean that POST is one of the HTTP _methods_ - it definitely is 
NOT a header and would not be identified as such by Pound.

Re. spam: you may want to have a look at the new pf capabilities in OpenBSD 
3.4. In conjunction with spamd it can modify dinamically the rules; once a 
connection was identified as originating with a spammer it can (for example) 
reduce the TCP window to a single character per packet - a single message 
would take half an hour to come through (and it would be immediately 
rejected).

However this is very much outside the scope of this mailing list (though very 
enjoyable in itself)...
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-1-920 4904

Robert Segall explained:

> I suspect you mean that POST is one of the HTTP _methods_ - it definitely is 
> NOT a header and would not be identified as such by Pound.


so maybe then I should take pound, and make it a spammer trap and call it 
pound-sand.  ;-)  any objections?


> Re. spam: you may want to have a look at the new pf capabilities in OpenBSD 
> 3.4. In conjunction with spamd it can modify dinamically the rules; once a 
> connection was identified as originating with a spammer it can (for example) 
> reduce the TCP window to a single character per packet - a single message 
> would take half an hour to come through (and it would be immediately 
> rejected).

in other words basically the same thing I was trying to do with pound.  I'll 
also do the same thing with my antispam system (camram) and a firewall project 
I'm associated with (IPCop).

> However this is very much outside the scope of this mailing list (though very

> enjoyable in itself)...

I can take a hint.  Thank you all for the help.  I'm very impressed with how 
easy this was to get running once I got the documentation stuff straightened 
out.  This is definitely going into my toolkit of handy-dandy tricks.

---eric