headers
Mike Cardwell | 1 Feb 19:22

Incomplete SSL negotiation information

My server has somehow found its self on the end of some strange
behaviour originating from the Pushdo botnet as described here:

http://www.shadowserver.org/wiki/pmwiki.php/Calendar/20100129

The infected hosts basically connect to the HTTPS port, send some
garbage and then disconnect without the SSL negotiation even being
completed. My error log is full of stuff like this:

[Mon Feb 01 18:19:37 2010] [error] unusably short session_id provided (1
bytes)

Annoyingly for some reason Apache doesn't log the IP address in this
circumstance. Is there anything I can do with ModSecurity to gather more
information on this problem or to mitigate it somehow?

--

-- 
Mike Cardwell    : UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/       #06920226
Technical Blog   : Tech Blog  - https://secure.grepular.com/
Spamalyser       : Spam Tool  - http://spamalyser.com/

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
mod-security-users mailing list
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ivan Ristic | 1 Feb 19:52
Picon

Re: Incomplete SSL negotiation information

On Mon, Feb 1, 2010 at 6:22 PM, Mike Cardwell
<modsecurity <at> lists.grepular.com> wrote:
> My server has somehow found its self on the end of some strange
> behaviour originating from the Pushdo botnet as described here:
>
> http://www.shadowserver.org/wiki/pmwiki.php/Calendar/20100129
>
> The infected hosts basically connect to the HTTPS port, send some
> garbage and then disconnect without the SSL negotiation even being
> completed.

I got a couple of unusual SSL handshakes too. But only a couple.

> My error log is full of stuff like this:
>
> [Mon Feb 01 18:19:37 2010] [error] unusably short session_id provided (1
> bytes)

Do you possibly have any "GET /" entries in your access logs somewhere?

> Annoyingly for some reason Apache doesn't log the IP address in this
> circumstance. Is there anything I can do with ModSecurity to gather more
> information on this problem or to mitigate it somehow?

No. There's nothing ModSecurity can do if the SSL handshake does not
go through, I am afraid.

> --
> Mike Cardwell    : UK based IT Consultant, Perl developer, Linux admin
> Cardwell IT Ltd. : UK Company - http://cardwellit.com/       #06920226
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ken S. | 1 Feb 21:23
Picon

The 'exec' Action and Available Variables

My question is about which variables are available to scripts running
from the 'exec' action.

I had posted earlier about wanting to log all POST data to a file
separate from the Apache error_log.
(http://article.gmane.org/gmane.comp.apache.mod-security.user/7099)
Ryan was kind enough to point me to the 'exec' action in the
documentation.  So I began developing a Bash script to handle this for
me; Bash is the most light-weight language that I know.  My script
works exactly as I want it when I run it as the "action" from a web
form, but does not capture any POST data when run from as the exec
action from my rule, but it does log all the other data from the
script; i.e date, referrer, etc.  You can see it at:
http://www.imacollector.com/test-post.htm

This is the rule I have in my modsecurity_crs_15_customrules.conf file:

# Log POST data to a file
SecRule REQUEST_METHOD "^POST$"
"phase:2,t:none,noauditlog,log,pass,exec:/usr/local/apache2/bin/logpostvars.sh"

The documentation says:
"... Some transaction information will be placed in environment
variables. All the usual CGI environment variables will be there. ..."

so I suspect all I need to do is to know which environment variable
stores the POST data and then split it in to key/value pairs and
continue.

If anyone could help me get over this last hurdle, I would be golden.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ryan Barnett | 1 Feb 23:49

Re: The 'exec' Action and Available Variables

I believe that you will need to also use the setenv action and use macro expansion to populate the
request_body data into the ENV that apache will use.  Something like this added to your action list
(untested) -

setenv:post_data=%{request_body}

Then you can call up the post_data env data in your script.

Ryan C. Barnett
Director of Application Security Research
Breach Security, Inc.
Ryan.Barnett <at> Breach.com 
www.Breach.com 

----- Original Message -----
From: Ken S. <shawing <at> gmail.com>
To: mod-security-users <at> lists.sourceforge.net <mod-security-users <at> lists.sourceforge.net>
Sent: Mon Feb 01 15:23:52 2010
Subject: [mod-security-users] The 'exec' Action and Available Variables

My question is about which variables are available to scripts running
from the 'exec' action.

I had posted earlier about wanting to log all POST data to a file
separate from the Apache error_log.
(http://article.gmane.org/gmane.comp.apache.mod-security.user/7099)
Ryan was kind enough to point me to the 'exec' action in the
documentation.  So I began developing a Bash script to handle this for
me; Bash is the most light-weight language that I know.  My script
works exactly as I want it when I run it as the "action" from a web
(Continue reading)

Permalink | Reply | 1 comment |
headers
christian.folini | 2 Feb 10:26
Picon
Favicon

Re: Incomplete SSL negotiation information

Hi there,

>> Annoyingly for some reason Apache doesn't log the IP address in this 
>> circumstance. Is there anything I can do with ModSecurity to gather 
>> more information on this problem or to mitigate it somehow?
> 
> No. There's nothing ModSecurity can do if the SSL handshake does not go through, I am afraid.

What is worse, an attacker has the possibility to 
combine this attack with the slowloris / request-delay technique.
Within the ssl handshake, the defender is almost blind.

This came up before:
http://article.gmane.org/gmane.comp.apache.mod-security.user/1923
Look for "attack #2".

Best,

Christian Folini

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ivan Ristic | 2 Feb 12:05
Picon

Re: Incomplete SSL negotiation information

Hmmm, I would expect the address to show in mod_status output...

Assuming that's correct, you can use the apache-protect script from
the Apache httpd tools project (http://www.apachesecurity.net/tools/).

On Tue, Feb 2, 2010 at 9:26 AM,  <christian.folini <at> post.ch> wrote:
> Hi there,
>
>>> Annoyingly for some reason Apache doesn't log the IP address in this
>>> circumstance. Is there anything I can do with ModSecurity to gather
>>> more information on this problem or to mitigate it somehow?
>>
>> No. There's nothing ModSecurity can do if the SSL handshake does not go through, I am afraid.
>
> What is worse, an attacker has the possibility to
> combine this attack with the slowloris / request-delay technique.
> Within the ssl handshake, the defender is almost blind.
>
> This came up before:
> http://article.gmane.org/gmane.comp.apache.mod-security.user/1923
> Look for "attack #2".
>
> Best,
>
> Christian Folini
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
(Continue reading)

Permalink | Reply | 2 comments |
headers
christian.folini | 2 Feb 12:43
Picon
Favicon

Re: Incomplete SSL negotiation information

> Hmmm, I would expect the address to show in mod_status output...

Nope. mod_status will not report the IP during the ssl-handshake.
The IP-Address is being set in the post-read-request phase.

See http://www.mail-archive.com/users <at> httpd.apache.org/msg24843.html

But I reckon apache could be patched in this regard.

> Assuming that's correct, you can use the apache-protect script 
> from the Apache httpd tools project (http://www.apachesecurity.net/tools/).

I do not think it is viable to monitor mod_status during a
DoS attack. However, mod_qos has the option to give certain
IPs priority over the rest of the world. This would guarantee
access to mod_status despite the server being blocked
(I have not tested this in practice though).

Regs,

Christian

On Tue, Feb 2, 2010 at 9:26 AM,  <christian.folini <at> post.ch> wrote:
> Hi there,
>
>>> Annoyingly for some reason Apache doesn't log the IP address in this 
>>> circumstance. Is there anything I can do with ModSecurity to gather 
>>> more information on this problem or to mitigate it somehow?
>>
>> No. There's nothing ModSecurity can do if the SSL handshake does not go through, I am afraid.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ivan Ristic | 2 Feb 13:20
Picon

Re: Incomplete SSL negotiation information

On Tue, Feb 2, 2010 at 11:43 AM,  <christian.folini <at> post.ch> wrote:
>> Hmmm, I would expect the address to show in mod_status output...
>
> Nope. mod_status will not report the IP during the ssl-handshake.
> The IP-Address is being set in the post-read-request phase.
>
> See http://www.mail-archive.com/users <at> httpd.apache.org/msg24843.html

That's too silly.

> But I reckon apache could be patched in this regard.

It should also be easy to write a new module to log IP addresses as
new connections are open.

>> Assuming that's correct, you can use the apache-protect script
>> from the Apache httpd tools project (http://www.apachesecurity.net/tools/).
>
> I do not think it is viable to monitor mod_status during a
> DoS attack.

It can be, but you'll need to use mod_backdoor, which gives you
guaranteed access, which would be needed to get to mod_status.

> However, mod_qos has the option to give certain
> IPs priority over the rest of the world. This would guarantee
> access to mod_status despite the server being blocked
> (I have not tested this in practice though).

Very interesting module. And so is mod_parp. I'll need to give them a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ryan Barnett | 2 Feb 15:22

Re: Incomplete SSL negotiation information

On Monday 01 February 2010 01:22:23 pm Mike Cardwell wrote:
> My server has somehow found its self on the end of some strange
> behaviour originating from the Pushdo botnet as described here:
> 
> http://www.shadowserver.org/wiki/pmwiki.php/Calendar/20100129
> 
> The infected hosts basically connect to the HTTPS port, send some
> garbage and then disconnect without the SSL negotiation even being
> completed. My error log is full of stuff like this:
> 
> [Mon Feb 01 18:19:37 2010] [error] unusably short session_id provided (1
> bytes)
> 
> Annoyingly for some reason Apache doesn't log the IP address in this
> circumstance. Is there anything I can do with ModSecurity to gather more
> information on this problem or to mitigate it somehow?
> 

Mike,
Do you happen to have TLS 1.2 enabled on your web server?  We are starting to get reports 
from our commercial WebDefend users about SSL error events with the following message -

Client violated the SSL protocol
unknown SSL version 0x303 in SSL record header

At this point, we are not sure if this is related to PushDo botnet or not, however our DEV 
team believes that this may be related to TLS 1.2.  Perhaps PushDo clients are initiating 
TLS 1.2 connections.

Please confirm.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Cardwell | 2 Feb 15:51

Re: Incomplete SSL negotiation information

On 02/02/2010 14:22, Ryan Barnett wrote:

>> My server has somehow found its self on the end of some strange
>> behaviour originating from the Pushdo botnet as described here:
>>
>> http://www.shadowserver.org/wiki/pmwiki.php/Calendar/20100129
>>
>> The infected hosts basically connect to the HTTPS port, send some
>> garbage and then disconnect without the SSL negotiation even being
>> completed. My error log is full of stuff like this:
>>
>> [Mon Feb 01 18:19:37 2010] [error] unusably short session_id provided (1
>> bytes)
>>
>> Annoyingly for some reason Apache doesn't log the IP address in this
>> circumstance. Is there anything I can do with ModSecurity to gather more
>> information on this problem or to mitigate it somehow?
>
> Mike,
> Do you happen to have TLS 1.2 enabled on your web server?  We are starting to get reports
> from our commercial WebDefend users about SSL error events with the following message -
>
> Client violated the SSL protocol
> unknown SSL version 0x303 in SSL record header
>
> At this point, we are not sure if this is related to PushDo botnet or not, however our DEV
> team believes that this may be related to TLS 1.2.  Perhaps PushDo clients are initiating
> TLS 1.2 connections.
>
> Please confirm.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane