Apache Server configuration support - Rewriting long URIs from viruses... shortening log files

Author

Rewriting long URIs from viruses... shortening log files

Leon Dang

2004-04-03, 4:33 am

Hi,

Suddenly there's been a burst of viruses doing a SEARCH
/\x90...etc...etc and the log file is ever growing so big. Apache does
have custom logging features, but I can't find a log line limit for
URIs which would be convenient. So I feel that the only resort is to
use mod_rewrite which is currently voodoo for me. Has anyone used
mod_rewrite to shrink these long URIs? Or can someone give me a simple
example of how to eliminate these SEARCH requests?

Thanks,
Leon

Richard Antony Burton

2004-04-03, 6:33 am

"Leon Dang" <zero2k@ausi.com> wrote in message
news:f902d5c.0404030117.772677a2@posting.google.com...

> Or can someone give me a simple
> example of how to eliminate these SEARCH requests?

Try something like this:

SetEnvIf Request_Method ^SEARCH$ worm
CustomLog logs/access.log combined env=!worm

This will prevent logging of all search requests. If you want some to be logged
you will need to find a better pattern to match just the worm with. You can add
as many SetEnvIf lines as you like to identify lots of different worms.

Richard.

Davide Bianchi

2004-04-03, 6:33 am

Leon Dang <zero2k@ausi.com> wrote:
> /\x90...etc...etc and the log file is ever growing so big. Apache does
> have custom logging features

See the documentation of Apache about conditional logging.
Davide

--
| Real computer scientists despise the idea of actual hardware.
| hardware has limitations, software doesn't. It's a real shame that
| Turing machines are so poor at I/O.
|

HansH

2004-04-03, 6:33 am

"Leon Dang" <zero2k@ausi.com> schreef in bericht
news:f902d5c.0404030117.772677a2@posting.google.com...
> Suddenly there's been a burst of viruses doing a SEARCH
> /\x90...etc...etc and the log file is ever growing so big. Apache does
> have custom logging features, but I can't find a log line limit for
> URIs which would be convenient. So I feel that the only resort is to
> use mod_rewrite which is currently voodoo for me. Has anyone used
> mod_rewrite to shrink these long URIs? Or can someone give me a simple
> example of how to eliminate these SEARCH requests?
A lovely WebDAV exploit attempt pumping 32k per request into the log ...
.... you cannot eliminate the request, but on the clients side or by blokking
them in a firewal

Googled how to conditionally avoid logging
SetEnvIfNoCase Request_URI "^/\\x90/" dontlog
CustomLog logs/access_log combined env=!dontlog

then tweaked it to keep a log entry with a (blundly) trimmed URI
SetEnvIfNoCase Request_URI "^/\\x90/" dontlog
CustomLog logs/access_log "%h %l %m %u %t env=!dontlog
CustomLog logs/access_log "%h %l %m \"x90\" %t env=dontlog

Good thing is you wonn't need voodoo-master mod_rewrite ...
.... hope mod_setenvif came standard with your system

All untested, but still it may give your thoughts a new direction.

HansH

Doug

2004-04-03, 5:33 pm

"HansH" <hans@niet.op.het.net> wrote in message
news:c4m4vo$v9i$1@news.cistron.nl...
> "Leon Dang" <zero2k@ausi.com> schreef in bericht
> news:f902d5c.0404030117.772677a2@posting.google.com...
> A lovely WebDAV exploit attempt pumping 32k per request into the log ...
> ... you cannot eliminate the request, but on the clients side or by
blokking
> them in a firewal
>
> Googled how to conditionally avoid logging
> SetEnvIfNoCase Request_URI "^/\\x90/" dontlog
> CustomLog logs/access_log combined env=!dontlog
>
> then tweaked it to keep a log entry with a (blundly) trimmed URI
> SetEnvIfNoCase Request_URI "^/\\x90/" dontlog
> CustomLog logs/access_log "%h %l %m %u %t env=!dontlog
> CustomLog logs/access_log "%h %l %m \"x90\" %t env=dontlog
>
> Good thing is you wonn't need voodoo-master mod_rewrite ...
> ... hope mod_setenvif came standard with your system
>
> All untested, but still it may give your thoughts a new direction.
>
> HansH

Thank You!!!

I have been looking for an answer to this and Google for once has not been
my friend. Must be searching on the wrong thing. Could be most were how to
patch the sieve IIS servers.

Doug

Leon Dang

2004-04-04, 1:33 am

"Doug" <dsommer@NOSPAM.sommer.gotdns.com> wrote in message news:<406f3185$1_1@newspeer2.tds.net>...
> "HansH" <hans@niet.op.het.net> wrote in message
> news:c4m4vo$v9i$1@news.cistron.nl...
> blokking
>
> Thank You!!!
>
> I have been looking for an answer to this and Google for once has not been
> my friend. Must be searching on the wrong thing. Could be most were how to
> patch the sieve IIS servers.
>
> Doug

Thanks Hans too. See how it goes and post a result when I find one
that really works.

Leon

Leon Dang

2004-04-04, 1:33 am

"Richard Antony Burton" <richardaburton-NOSPAM-@hotmail.com> wrote in message news:<JEwbc.12306314$Of.2054874@news.easynews.com>...
> "Leon Dang" <zero2k@ausi.com> wrote in message
> news:f902d5c.0404030117.772677a2@posting.google.com...
>
>
> Try something like this:
>
> SetEnvIf Request_Method ^SEARCH$ worm
> CustomLog logs/access.log combined env=!worm
>
> This will prevent logging of all search requests. If you want some to be logged
> you will need to find a better pattern to match just the worm with. You can add
> as many SetEnvIf lines as you like to identify lots of different worms.
>
> Richard.

I did something similar:

SetEnvIfNoCase Request_Method "SEARCH" dontlog

(no ^, $ signs) but that didn't work... I'll try your method out.

Thanks,
Leon

Purl Gurl

2004-04-04, 8:33 pm

Leon Dang wrote:

> Richard Antony Burton wrote:

(snipped)
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
> I did something similar:

> SetEnvIfNoCase Request_Method "SEARCH" dontlog

> (no ^, $ signs) but that didn't work... I'll try your method out.

I have had no success with any of the methods
presented and a few of my own.

Appears a SEARCH method cannot be captured under
any circumstances, not for mod_rewrite, not for
mod_security nor for custom access logs. I also
found IP Address blocking fails for SEARCH methods.

I did hack my compiled Apache core to include
the SEARCH method, but this failed as well.
Apache loads and runs just fine, but will
not recognize that specific method.

Appears we are stuck with Webdav and massive
thirty-thousand bytes plus log entries. Clearly
this is a minor vulnerability in Apache. Perhaps
Apache developers will address this in the future.

With enough hits at a fast pace, a successful
Denial Of Service attack could be had.

I am currently looking at developing a transparent
firewall to address this problem Apache cannot.

I will file a bug report with Apache.

Kira

Leon Dang

2004-04-05, 1:33 am

After looking at Kira's report, I made a different attempt to get
around things. A little hacky (and ugly), but it'll do for now until
Apache patches things up, which I hope they do.

-----

SetEnvIfNoCase Request_Method "OPTIONS" validreq
SetEnvIfNoCase Request_Method "GET" validreq
SetEnvIfNoCase Request_Method "POST" validreq
SetEnvIfNoCase Request_Method "HEAD" validreq
SetEnvIfNoCase Request_Method "PUT" validreq

SetEnvIfNoCase Request_URI "\.(png|gif|jpe?g|wbmp)$" !validreq
dontlog=1
SetEnvIfNoCase Request_URI "^/(css|status)/*" !validreq dontlog=1
SetEnvIfNoCase Request_URI "^/scripts/*" !validreq dontlog=1
SetEnvIfNoCase Request_URI "(root\.exe|cmd\.exe|default\.ida)"
!validreq dontlog=1
SetEnvIfNoCase Request_URI "(null\.ida)" !validreq dontlog=1
SetEnvIfNoCase Request_URI "null\.ida" !validreq dontlog=1
SetEnvIfNoCase Request_URI "^/NULL\.IDA.*" !validreq dontlog=1

CustomLog /www/logs/access_log common env=validreq

----

Tried the following, but pretty much useless:

SetEnvIfNoCase Request_Method "^SEAR.*" !validreq virussed=1
SetEnvIfNoCase Request_URI "^SEAR.*" !validreq virussed=1
SetEnvIfNoCase Request_URI "^/\x90.*" !validreq virussed=1
CustomLog /www/logs/virus_log "%h %l %m \"x90\" %t" env=virussed

----

Leon.

zero2k@ausi.com (Leon Dang) wrote in message news:<f902d5c.0404030117.772677a2@posting.google.com>...
> Hi,
>
> Suddenly there's been a burst of viruses doing a SEARCH
> /\x90...etc...etc and the log file is ever growing so big. Apache does
> have custom logging features, but I can't find a log line limit for
> URIs which would be convenient. So I feel that the only resort is to
> use mod_rewrite which is currently voodoo for me. Has anyone used
> mod_rewrite to shrink these long URIs? Or can someone give me a simple
> example of how to eliminate these SEARCH requests?
>
> Thanks,
> Leon

Purl Gurl

2004-04-05, 1:35 am

Leon Dang wrote:

(snipped)

> After looking at Kira's report, I made a different attempt to get
> around things. A little hacky (and ugly), but it'll do for now until
> Apache patches things up, which I hope they do.

Unfortunately, Leon, we are on our own. Apache will
not be helping with this problem.

See my "Bug Report" article for details.

Leon, I have been working on this Webdav problem
for the past three months. Like you, I have tried
custom log directives. None work.

You are aware of my other tested methods, none
of which work.

Problem is Apache will not allow hooking into
an error 414 condition. Appears there is absolutely
nothing which can be done via Apache.

I am currently researching transparent firewalls
to discover if there is a reasonable and affordable
method to deal with Webdav. Best price I found for
a firmware transparent firewall is four-thousand
to five-thousand dollars. Clearly this is out.

No help from Apache. Effective solutions cost
thousands of dollars. This is a problem.

I will continue to hack Apache core with
hopes of writing in programming which Apache
Org should do and should have done.

Should I come up with something which is
reasonable and easy to effect, I will let
you know here in this newsgroup.

Kira

Joachim MÃ¦land

2004-04-05, 2:33 am

On Sun, 04 Apr 2004 22:11:04 -0700, Purl Gurl wrote:

> Unfortunately, Leon, we are on our own. Apache will not be helping with
> this problem.

Are you sure they're not fixing this "secretly", in order to buy some
extra time...?

> I am currently researching transparent firewalls to discover if there is
> a reasonable and affordable method to deal with Webdav. Best price I
> found for a firmware transparent firewall is four-thousand to
> five-thousand dollars. Clearly this is out.
>
> No help from Apache. Effective solutions cost thousands of dollars. This
> is a problem.

How about making iptables on your Apache box block the offending IP
address, better yet, redirect requests to port 80, (from this IP address),
to another port and let your "Perl "honeypot" program, return a single
command line prompt"...? ;P

I'm certainly not an iptables guru, but this should be possible...(?) Even
letting PERL rewrite your chains on the fly...

--
mvh/regards
Joachim Mæland

If everything seems under control, you're just not going fast enough.
-Mario Andretti

Richard Antony Burton

2004-04-05, 5:34 am

"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:4070AA48.A7B0CA75@purlgurl.net...

[color=darkred]
> I have had no success with any of the methods
> presented and a few of my own.

Well I tested it on my own machine before I suggested it, and it stopped all
search entries in the access logs.

Richard.

Richard Antony Burton

2004-04-05, 5:34 am

"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:4070EA68.3F965B56@purlgurl.net...

> I will continue to hack Apache core with
> hopes of writing in programming which Apache
> Org should do and should have done.

The apache software foundation owes you nothing. Perhaps you think this feature
would be useful, and I would probably agree, but that doesn't mean you are
entitled to say it is something that apache should have done.

However because it is Open Source you can do it yourself, and if you do a good
job, maybe they will put your code into the product, but don't assume they owe
you that because they don't.

Richard.

Leon Dang

2004-04-05, 7:33 am

Purl Gurl <purlgurl@purlgurl.net> wrote in message news:<4070EA68.3F965B56@purlgurl.net>...
> Leon Dang wrote:
>
> (snipped)
>
>
> Unfortunately, Leon, we are on our own. Apache will
> not be helping with this problem.
>
> See my "Bug Report" article for details.
>
>
> Leon, I have been working on this Webdav problem
> for the past three months. Like you, I have tried
> custom log directives. None work.
>
> You are aware of my other tested methods, none
> of which work.
>
> Problem is Apache will not allow hooking into
> an error 414 condition. Appears there is absolutely
> nothing which can be done via Apache.
>
> I am currently researching transparent firewalls
> to discover if there is a reasonable and affordable
> method to deal with Webdav. Best price I found for
> a firmware transparent firewall is four-thousand
> to five-thousand dollars. Clearly this is out.
>
> No help from Apache. Effective solutions cost
> thousands of dollars. This is a problem.
>
> I will continue to hack Apache core with
> hopes of writing in programming which Apache
> Org should do and should have done.
>
> Should I come up with something which is
> reasonable and easy to effect, I will let
> you know here in this newsgroup.
>
>
> Kira

Hi Kira,

I can understand the agony, I hate bugs. I took a look at the source
code, and if I had time, I would write some modifications to it to
cater for cases such as this. I think the first thing that I'll
implement is the ability to have length limits on log lines... I
really wish I had a couple days free, it looks basic enough.

Intercepting 414 errors is tougher to make work in a known stable
state.

In the meantime, I've tested my hack for CustomLog and SetEnvIf and
it's no longer logging the request methods that I am allowing. But
then it could cause issues such as bugs/flaws not being logged which I
have a fear of.

I'm interested in any fixes that can be applied to Apache to resolve
issues. Isn't that why we're using Apache in the first place right?

Leon

Richard Antony Burton

2004-04-05, 7:33 am

"Leon Dang" <zero2k@ausi.com> wrote in message
news:f902d5c.0404050241.276e814c@posting.google.com...

> I'm interested in any fixes that can be applied to Apache to resolve
> issues. Isn't that why we're using Apache in the first place right?

Probably you are using apache because you like the idea that people (including
yourself) can write patches to it. However it doesn't mean that you can always
expect to find a patch to do what you want.

I think we have already established that this is not a bug, but a feature
request. You have a few options for a feature request, convince an apache
developer to introduce it, do it yourself, get a friend to do it, or get a fully
supported version of apache. You could try IBM HTTP Server, which is based on
apache, but is supported (at cost of course) and so you could probably ask them
to introduce the feature you requested. I imagine that it would eventually be
fed back into apache too.

Richard.

Purl Gurl

2004-04-05, 9:34 am

Leon Dang wrote:

> Purl Gurl wrote:

(snipped)
[color=darkred]
[color=darkred]

[color=darkred]
> In the meantime, I've tested my hack for CustomLog and SetEnvIf and
> it's no longer logging the request methods that I am allowing. But
> then it could cause issues such as bugs/flaws not being logged which I
> have a fear of.

Leon, would you do me a favor and share your code?

I have been trying several methods to hook into an
error 414 condition and truncate length of entries,
with no luck. I have not tried to eliminate those
entries entirely has you have.

Perhaps with code example I can discover why I cannot
truncate the entries. Like you, I want to at least
have short entries so I can file formal complaints
with an offending server.

Apache Org indicates it is not possible to hook those
entries. I am doubtful of their opinion.

Thanks, Leon, for your help,

Kira

Purl Gurl

2004-04-05, 11:33 am

Joachim MÃ wrote:

> Purl Gurl wrote:

(snipped)

[color=darkred]
> How about making iptables on your Apache box block the offending IP
> address, better yet, redirect requests to port 80, (from this IP address),
> to another port and let your "Perl "honeypot" program, return a single
> command line prompt"...? ;P

> I'm certainly not an iptables guru, but this should be possible...(?) Even
> letting PERL rewrite your chains on the fly...

Thanks, Joachim. This is a very good idea.

I have honeyd (honeypot program) and have played with
this since early inception. Last night, I started
researching iptables for possible solutions in keeping
with your suggestion. It will take me a month of Sundays
to become very familiar with this possibility!

There is one drawback; Win32 systems. Iptables are rather
challenging on those systems.

On Perl, this is a great programming language, very
powerful, very useful, but also slow and CPU intensive.
Nonetheless, as you have probably discovered, I am
at an expert level in PERL programming and well know
the potential here.

Most of my comments on using PERL to devastate an
offending machine, are wishful thinking. Although
easy to do, easy to devastate a machine with Perl,
I will not do this; it is unethical. Fun, though,
to consider taking revenge on those idiots!

Well, if I become angry enough. A few times over the
years I have engaged in less than ethical activities,
and usually felt guilty later. I do have quite a few
Perl based security responses in place, but all are
rather benign, mostly to let offensive people know
they are not immune from consequences.

Perl is highly adaptable to this task but would add
a lot of system resource usage, slowing down overall
performance, significantly. Still, PERL could be used
for a temporary short lived solution.

My hope is to find a solution for this 414 error problem
which can be adapted by all in an easy fashion which
requires no advanced skills. There is a need for a solution,
and a need for an immediate solution.

I will continue to research usage of iptables as you
suggest and will let you know if I find a method
which is worthwhile and easy to adapt.

Thanks for your input, Joachim! You have added very
beneficial comments for all to enjoy. Perhaps another
with expertise in iptables will jump in and suggest
some easy solutions for all to use.

Kira

Richard Antony Burton

2004-04-05, 1:35 pm

"Leon Dang" <zero2k@ausi.com> wrote in message
news:f902d5c.0404050241.276e814c@posting.google.com...

> I can understand the agony, I hate bugs. I took a look at the source
> code, and if I had time, I would write some modifications to it to
> cater for cases such as this. I think the first thing that I'll
> implement is the ability to have length limits on log lines... I
> really wish I had a couple days free, it looks basic enough.

The problem with simply truncating the whole log line is that URI isn't normally
the last item on the log line, so you would lose all the items that follow. If
you just want to truncate the URI (%r) that is pretty easy, just for a fun I
tried it this afternoon and the modification to mod_log_config is pretty simple.

After the modification I just changed my config to this (i.e. I inserted
"{200}"):

LogFormat "%h %l %u %t \"%{200}r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""
combined
CustomLog logs/access.log combined

Now the URI (only) will be truncated to 200 (if larger), without affecting the
rest of the log entry. If you've been looking at the logging code, you can
probably see how to make the same mod I did for this example.

Richard.

Purl Gurl

2004-04-05, 1:35 pm

Richard Antony Burton wrote:

> Leon Dang wrote:

(snipped)

> After the modification I just changed my config to this (i.e. I inserted
> "{200}"):

> LogFormat "%h %l %u %t \"%{200}r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""

As a professional programmer it is my long habit
to debug, test and verify my programming techniques
well before making them public.

LogFormat "%a %h %t \"%{200}r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

You will discover with prudent testing, your method
does not work for a SEARCH request method. I will
encourage you to debug, test and verify your methods
before making them public.

Perhaps my Apache handles this differently than yours?

Did you verify success by examination of your log
after a Webdav exploit arrives?

Kira

Richard Antony Burton

2004-04-05, 1:35 pm

"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:4071943F.5592C030@purlgurl.net...

>
\"%{User-Agent}i\""[color=darkred]
>
> As a professional programmer it is my long habit
> to debug, test and verify my programming techniques
> well before making them public.

So you are an English professor and a professional programmer? That must keep
you busy. Anyway a good tip!

> LogFormat "%a %h %t \"%{200}r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""
combined
>
> You will discover with prudent testing, your method
> does not work for a SEARCH request method. I will
> encourage you to debug, test and verify your methods
> before making them public.

Well I can't claim to have tested it extensively, but it did occur to me to test
it for the actual scenario in question. And yes it does work perfectly well in
search requests. I would not have stated so confidently that it was working for
me if it was just a theory, and not something I had actually tried myself.
However I do greatly appreciate your encouragment, how silly would I look
otherwise (oh wait, that's what you were trying to suggest, but I guess it
backfired since I did test it).

Since you seem so sure that it shouldn't work I'll assume you are familiar with
the area of code I made the small modification in, and what modification I made
(despite the fact that I didn't tell you what I actually did), and so could you
perhaps explain why you say that it can't work for search request?

> Perhaps my Apache handles this differently than yours?

Aparently so. Of course IIRC you are using apache 1.3? Whereas I use 2.0.
Perhaps this is the issue.

> Did you verify success by examination of your log
> after a Webdav exploit arrives?

I don't get hit by them very often, but I did test with the same request string
in my log from a previous attack attempt.

Richard.

Purl Gurl

2004-04-05, 2:33 pm

Richard Antony Burton wrote:

> Purl Gurl wrote:

(snipped)

> Aparently so. Of course IIRC you are using apache 1.3? Whereas I use 2.0.
> Perhaps this is the issue.

I am skeptical.

Again, I will encourage you to debug, test and verify
your methods as correct before making them public.

Related to this thread, you have provided bad code.

Kira

Purl Gurl

2004-04-05, 2:33 pm

Richard Antony Burton, or is it Pete, wrote:

> Purl Gurl wrote:

(snipped)

> So you are an English professor and a professional programmer?
> That must keep you busy. Anyway a good tip!

You will also discover through internet resources, I am
a professional stock market day trader making significant
profits, daily. I am doing this now as I write this.

Tips, I have none which would benefit you, personally.

Purl Gurl

Richard Antony Burton

2004-04-05, 2:33 pm

"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:40719C61.145431BE@purlgurl.net...

> You will also discover through internet resources, I am
> a professional stock market day trader making significant
> profits, daily. I am doing this now as I write this.

You forgot to mention you are also 12, and any minute now your dad is going walk
in and find you looking at porn, then you'll be banned from using the computer,
which will be nice for the rest of us.

Richard.

Richard Antony Burton

2004-04-05, 2:33 pm

"Purl Gurl" <purlgurl@purlgurl.net> wrote in message
news:407199D8.97EEFB21@purlgurl.net...

>
> I am skeptical.

Well I've told you that it works, so there is nothing to be sceptical about.

> Again, I will encourage you to debug, test and verify
> your methods as correct before making them public.
>
> Related to this thread, you have provided bad code.

Again, I really appreciate your encouragement, I don't know how I'd get through
the day without it.

As for the bad code for the thread, this thread really has nothing to do with
you and your install of Apache 1.3. Leon Dang hasn't said here what verison of
apache he is using, so I went with the assumption that he would be using the
latest and recommended version (i.e. 2.0).

As for providing bad code, I haven't provided any code at all. I have simply
discussed a way in which I have achived something you have been unable with a
code change.

Richard.

Purl Gurl

2004-04-05, 4:33 pm

Leon Dang wrote:

> Purl Gurl wrote:

(snipped)

[color=darkred]
> I can understand the agony, I hate bugs. I took a look at the source
> code, and if I had time, I would write some modifications to it to
> cater for cases such as this. I think the first thing that I'll
> implement is the ability to have length limits on log lines... I
> really wish I had a couple days free, it looks basic enough.

> I'm interested in any fixes that can be applied to Apache to resolve
> issues. Isn't that why we're using Apache in the first place right?

Leon, I have found one cure which is beginning to work;
writing formal complaints to offending servers.

Started hearing back from some servers today. One eliminated
all offending machines on its system. Another has reduced
the number of offending machines. Haven't heard from Charter
Communications yet, but have noticed hits per day from them
have dropped from an average five-hundred to a thousand per
day, down to only twenty-four today, so far.

Challenge is you have to keep pounding away at offending
servers on a daily basis. Have to keep hammering them
with email until they give in and take action.

Phone calls are very effective as well. * grins *

No software solution on the horizon for this problem
and I suspect none will be found, employing Apache.
Appears it is impossible to hook into a 414 error
regardless of methods employed.

Apache security has been alerted by their own team
and by me. A few have taken time to contact me and
to suggest solutions, which is appreciated. They
are now aware of this problem, or have been reminded
this problem still exists and won't go away.

Perhaps future releases will contain a fix for
these obvious bugs in Apache, maybe a patch will
come out, which would be nice.

I'll let you and all readers know if anything
new develops on this problem.

Hammer those offending servers with email!
Actually does work with persistence.

Purl Gurl

Leon Dang

2004-04-05, 7:35 pm

"Richard Antony Burton" <richardaburton-NOSPAM-@hotmail.com> wrote in message news:<i9hcc.12484766$Of.2084241@news.easynews.com>...
> "Purl Gurl" <purlgurl@purlgurl.net> wrote in message
> news:40719C61.145431BE@purlgurl.net...
>
>
> You forgot to mention you are also 12, and any minute now your dad is going walk
> in and find you looking at porn, then you'll be banned from using the computer,
> which will be nice for the rest of us.
>
> Richard.

Please, no bashing around... it just runs around in circles. I am a
S/W engineer, so that only matters to people who know and work with
me, and I make no claims of my ability. If I find a fix that others
would find helpful, I am more than happy to share it around.

Leon

Leon Dang

2004-04-05, 8:35 pm

"Richard Antony Burton" <richardaburton-NOSPAM-@hotmail.com> wrote in message news:<Jfhcc.12485092$Of.2084319@news.easynews.com>...
> "Purl Gurl" <purlgurl@purlgurl.net> wrote in message
> news:407199D8.97EEFB21@purlgurl.net...
>
>
> Well I've told you that it works, so there is nothing to be sceptical about.
>
>
> Again, I really appreciate your encouragement, I don't know how I'd get through
> the day without it.
>
> As for the bad code for the thread, this thread really has nothing to do with
> you and your install of Apache 1.3. Leon Dang hasn't said here what verison of
> apache he is using, so I went with the assumption that he would be using the
> latest and recommended version (i.e. 2.0).
>
> As for providing bad code, I haven't provided any code at all. I have simply
> discussed a way in which I have achived something you have been unable with a
> code change.
>
> Richard.

Sorry, should'a mentioned I am using the 1.3.x branch because it's
what I know is stable with php and other modules, and I have no need
for multithreading.

Leon

Richard Antony Burton

2004-04-06, 4:33 am

"Leon Dang" <zero2k@ausi.com> wrote in message
news:f902d5c.0404051447.56995a4e@posting.google.com...
> "Richard Antony Burton" <richardaburton-NOSPAM-@hotmail.com> wrote in message
news:<i9hcc.12484766$Of.2084241@news.easynews.com>...

> Please, no bashing around... it just runs around in circles. I am a
> S/W engineer, so that only matters to people who know and work with
> me, and I make no claims of my ability. If I find a fix that others
> would find helpful, I am more than happy to share it around.

No bashing was aimed at you. In fact I looked at this problem and came up with a
simple log shortening patch for you, not Purl Gurl. However, as it was for
apache 2, and you hadn't mentioned you were using 1.3 at the time, it is
unfortunatly of no use to you.

Richard.

2004-04-07, 11:34 pm

Running Apache/1.3.27 (Unix) here.

I have tried the suggestions that many of you have kindly recommended
without any luck. I even rebuilt iptables to add string matching which
hasn't blocked anything, although I am not 100% confident I did this
correctly, so may have missed something there. Loading the firewall does
indicate that string matching is enabled, however, that is a topic for
another group.

Is it fairly safe to say at this point, due to apaches limits on dealing
with 414 status codes, that this is not something that can be done with
the current versions? Or is it possible that there is still a potential
solution lurking out there somewhere? Just want to determine whether I
am wasting my time (or not) by still attempting to get rid of this
nuisance.

Any helpful/informative responses much appreciated.

thanks,
tz

Purl Gurl

2004-04-07, 11:34 pm

tz wrote:

(snipped)

> Running Apache/1.3.27 (Unix) here.

Excellent. Apache 1.3.27 is the best
version of all Apache releases. Next
two, .28 and .29 have some bugs.

Apache 1.3.27 is faster, more efficient
and more stable than version 2.x series.

Both versions are very nice but 2.x series
simply pales in comparsion to old Apache
when it comes to speed and efficiency.

> I have tried the suggestions that many of you have
> kindly recommended without any luck.

Don't let let this get you down. I have been working
on this, on and off, for a couple of years. Most
recently, intensely working on this for three months.

I have found no solutions.

> I even rebuilt iptables to add string matching which
> hasn't blocked anything, although I am not 100% confident
> I did this correctly, so may have missed something there.

Some here are experts on iptables and surely will help you.

> Is it fairly safe to say at this point, due to apaches limits on dealing
> with 414 status codes, that this is not something that can be done with
> the current versions?

Correct. Once Apache gets a hold of this, you are
completely out of the loop. There is literally
nothing to be done once Apache hooks a request,
and I do mean literally nothing; no ip blocking,
no directives, no modules, no logging control,
nada, zippo, nothing.

You must enter _before_ Apache, must get in "front"
of Apache. Port binding, router firewall, a type
of security hardware, whatever, you must inject
your method before Apache.

I looked at a PERL program which binds to port 80
and could be used for filtering before Apache.
However, I have written scripts like this before
and they are VERY SLOW. PERL is great but for
filtering port 80 before Apache, just not a
viable solution unless you are happy with old
28K modem like speeds, or slower.

As usual, any information I develop will be
shared in this group. Found a sticky honeypot
you might want to research. It does not solve
our problems but might be able to slow down
exploits to a more tolerable level. See
my most recent article "Sticky Honeypot."

Best,

Purl Gurl

Purl Gurl

2004-04-08, 12:34 am

tz wrote:

(snipped)

> I even rebuilt iptables to add string matching which
> hasn't blocked anything, although I am not 100% confident
> I did this correctly

Tz, read Hatema's articles posted late evening
this date under the topic, "Capture 414 Error...."

He provides information which you should
find very useful.

Purl Gurl

2004-04-08, 4:33 am

Purl Gurl <purlgurl@purlgurl.net> wrote in
news:4074C71F.5C5DE3E8@purlgurl.net:

Hi,

Thanks for your quick response.

> Excellent. Apache 1.3.27 is the best
> version of all Apache releases. Next
> two, .28 and .29 have some bugs.
>
> Apache 1.3.27 is faster, more efficient
> and more stable than version 2.x series.
>
> Both versions are very nice but 2.x series
> simply pales in comparsion to old Apache
> when it comes to speed and efficiency.

Glad you mentioned this as I was just considering an upgrade to
1.3.29. Plus the server in question is still on a 200MHz/430TX system ;)
It's pretty low traffic, but doesn't need any slowing down.

>
> Don't let let this get you down. I have been working
> on this, on and off, for a couple of years. Most
> recently, intensely working on this for three months.
>
> I have found no solutions.

Sounds like you have put a lot into this issue ...or "non-feature".
I admire your persistence.

>
> You must enter _before_ Apache, must get in "front"
> of Apache. Port binding, router firewall, a type
> of security hardware, whatever, you must inject
> your method before Apache.

I am still messing around with the syntax for string matching on
the iptables firewall, if I have any success I will pass it along.
Like I mentioned above, it's a low traffic machine so testing each
change takes some patience on my part while waiting for the next
hit.

> I looked at a PERL program which binds to port 80
> and could be used for filtering before Apache.
> However, I have written scripts like this before
> and they are VERY SLOW. PERL is great but for
> filtering port 80 before Apache, just not a
> viable solution unless you are happy with old
> 28K modem like speeds, or slower.

Yeah, that is not really an option for me (see above).

> As usual, any information I develop will be
> shared in this group. Found a sticky honeypot
> you might want to research. It does not solve
> our problems but might be able to slow down
> exploits to a more tolerable level. See
> my most recent article "Sticky Honeypot."

I will have a look at that.

>
> Best,
>
> Purl Gurl

(snipped)
> Tz, read Hatema's articles posted late evening
> this date under the topic, "Capture 414 Error...."
>
> He provides information which you should
> find very useful.

Just going through that thread now.

A couple servers I admin are hosted at rackspace and these entries no longer
appear in the apache logs, so they have most likely dealt with it at their
router or firewall (although they claim not to use one). I have written to
their support dept. and still waiting to hear from them, but as they have no
obligation to tell me how they have accomplished this, I'm not holding my
breath.

Thank you for your help,

cheers...
tz

deejay

2004-06-24, 3:29 pm

quote:
A couple servers I admin are hosted at rackspace and these entries no longer appear in the apache logs, so they have most likely dealt with it at their router or firewall (although they claim not to use one). I have written to their support dept. and still waiting to hear from them, but as they have no obligation to tell me how they have accomplished this, I'm not holding my breath.

Ok, so I have been holding my breath for some time now, despite your advice not to...

Has anyone found a fix for this annoyance yet? I get several of these entries every day in my logs. I would really like to find a way to block them, or have them moved to another log file using the SetEnvIfNoCase Request_URI "^/\x90/" dontlog method.

Please, if anyone has anything new to add here, please post it.

Thanks!

Erwin_D

2005-01-21, 6:49 pm

I found this on another forum... a bit late maybe, but better then never!

Someone actually read the Apache documentation and found you can filter the logs on status codes. Change the LogFormat to show like this:

LogFormat "%h %l %u %t \"%!414r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%!414r\" %>s %b \"%{Referer}i\"" common

Note the "%!414r\" part; this tells Apache NOT to log the URL if the request is generating a 414 error, and simply replaces it with a "-".

(Wouldn't you know... just as I'm about to test it myself, the exploit stays away!)

[EDIT:] It's WORKING! Here's the first filtered log:

216.167.144.125 - - [22/Jan/2005:02:11:50 +0100] "-" 414 334 "-" "-"