You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@httpd.apache.org by Ramon Casha <ra...@megabyte.net> on 2014/04/09 09:06:49 UTC

[users@httpd] Access control advice needed

I have a website running drupal which is currently under a continuous
botnet attack, which is causing major performance issues. I'm trying to
use apache's access control mechanism to block these requests.

Two characteristics of the attack requests are that they all use
HTTP/1.0, and a large percentage of them are within one domain.

When I look at my access log, most requests are coming in from:
134.230.153.27.broad.pt.fj.dynamic.163data.com.cn
129.199.159.27.broad.pt.fj.dynamic.163data.com.cn
...etc.

i tried blocking access using Apache's Deny From as follows:

<Directory /opt/drupal-7/>
Options +FollowSymLinks
AllowOverride All
Order Allow,Deny
Allow from all
Deny from .broad.pt.fj.dynamic.163data.com.cn
</Directory>

However this did not work - all requests are still being allowed in.
Note that the /opt/drupal-7 directory is a symlink to the actual
directory which has the full version number.

Also, since all the botnet requests are marked as HTTP/1.0, I tried to
restrict access to the user-registration pages using the protocol, as
follows:

SetEnvIf Request_Protocol "^HTTP/1\.0$" Bad_Req
<Location /utenti>
Order Allow,Deny
Deny from env=BadReq
</Location>

However this is blocking everything - HTTP/1.0 or 1.1. "/utenti" is the
prefix to the user registration page, password-reset page etc. I tried
changing around the Order, adding an "Allow from all" but in each case I
either end up blocking everyone or letting all requests through.

I'd appreciate any advice on how to implement the above or resolve this
issue in some other way.

--
Ramon Casha

Note: I have no control over the disclaimer message that will invariably
appear below.

DISCLAIMER
----------------------

The information transmitted in this message and any attachments is strictly confidential and intended only for the individual or entity to whom it is addressed.
Any form of unauthorised review, transmission, disclosure, publication, reproduction, modification or other use of, or the taking of any action in reliance upon any of the information contained in this e-mail by individuals or entities other than the intended recipient is strictly prohibited.
If you are not the named addressee or the person responsible for delivering the message to the named addressee and have received this communication in error, you must not disclose the contents of this e-mail to any other person; or make any copies thereof. If you are not the named recipient please delete/destroy any and all copies that may exist, whether in electronic or hard copy for and notify us immediately on the phone number indicated above and provide us with details about the said e-mail received in error.
Since the Internet is not a secure medium Megabyte cannot guarantee the privacy or confidentiality of any e-mail communications transmitted. All messages sent to and from Megabyte Ltd may be monitored and/or recorded to ensure compliance with internal policies and procedures. We disclaim all responsibility and liability whatsoever in relation to any errors or omissions that may reveal themselves in this message and in relation to any damage that may result from any such errors or omissions. We disclaim all responsibility and liability for any damage that may arise from the unauthorised acts of third parties and/or the corruption of any data contained in this message.
Thank you.

Re: [users@httpd] Access control advice needed

Posted by Oren <or...@taykey.com>.

Hi Ramon.
Why use apache for the block and not a firewall? its not apache related 
but i think its a better way of doing that.
You can add those addresses to blocking rules and reduce the load on the 
apache before they even reach it.
I am not sure which os you use but there are simple ways of doing that 
even if you dont have dedicated hardware.

Oren

On 04/09/2014 10:32 AM, Jan Vávra wrote:
> Hello,
>  try to use an IP address or subnet instead of 
> .broad.pt.fj.dynamic.163data.com.cn
>
> Jan.
>> Access control advice needed
>>
>> I have a website running drupal which is currently under a continuous
>> botnet attack, which is causing major performance issues. I'm trying to
>> use apache's access control mechanism to block these requests.
>>
>> Two characteristics of the attack requests are that they all use
>> HTTP/1.0, and a large percentage of them are within one domain.
>>
>> When I look at my access log, most requests are coming in from:
>> 134.230.153.27.broad.pt.fj.dynamic.163data.com.cn
>> 129.199.159.27.broad.pt.fj.dynamic.163data.com.cn
>> ...etc.
>>
>> i tried blocking access using Apache's Deny From as follows:
>>
>> <Directory /opt/drupal-7/>
>>    Options +FollowSymLinks
>>    AllowOverride All
>>    Order Allow,Deny
>>    Allow from all
>>    Deny from .broad.pt.fj.dynamic.163data.com.cn
>> </Directory>
>>
>> However this did not work - all requests are still being allowed in.
>> Note that the /opt/drupal-7 directory is a symlink to the actual
>> directory which has the full version number.
>>
>> Also, since all the botnet requests are marked as HTTP/1.0, I tried to
>> restrict access to the user-registration pages using the protocol, as
>> follows:
>>
>> SetEnvIf Request_Protocol "^HTTP/1\.0$" Bad_Req
>> <Location /utenti>
>>     Order Allow,Deny
>>     Deny from env=BadReq
>> </Location>
>>
>> However this is blocking everything - HTTP/1.0 or 1.1. "/utenti" is the
>> prefix to the user registration page, password-reset page etc. I tried
>> changing around the Order, adding an "Allow from all" but in each case I
>> either end up blocking everyone or letting all requests through.
>>
>> I'd appreciate any advice on how to implement the above or resolve this
>> issue in some other way.
>>
>> --
>> Ramon Casha
>>
>> Note: I have no control over the disclaimer message that will invariably
>> appear below.
>>
>>
>> *DISCLAIMER*
>>
>> /The information transmitted in this message and any attachments is 
>> strictly confidential and intended only for the individual or entity 
>> to whom it is addressed.
>> Any form of unauthorised review, transmission, disclosure, 
>> publication, reproduction, modification or other use of, or the 
>> taking of any action in reliance upon any of the information 
>> contained in this e-mail by individuals or entities other than the 
>> intended recipient is strictly prohibited.
>> If you are not the named addressee or the person responsible for 
>> delivering the message to the named addressee and have received this 
>> communication in error, you must not disclose the contents of this 
>> e-mail to any other person; or make any copies thereof. If you are 
>> not the named recipient please delete/destroy any and all copies that 
>> may exist, whether in electronic or hard copy for and notify us 
>> immediately on the phone number indicated above and provide us with 
>> details about the said e-mail received in error.
>> Since the Internet is not a secure medium Megabyte cannot guarantee 
>> the privacy or confidentiality of any e-mail communications 
>> transmitted. All messages sent to and from Megabyte Ltd may be 
>> monitored and/or recorded to ensure compliance with internal policies 
>> and procedures. We disclaim all responsibility and liability 
>> whatsoever in relation to any errors or omissions that may reveal 
>> themselves in this message and in relation to any damage that may 
>> result from any such errors or omissions. We disclaim all 
>> responsibility and liability for any damage that may arise from the 
>> unauthorised acts of third parties and/or the corruption of any data 
>> contained in this message.
>> Thank you./
>>
>

[users@httpd] OpenSSL "Heartbleed" Vulnerability (was:Re: [users@httpd] Access control advice needed)

Posted by Didier Spaier <di...@epsm.fr>.

On 09/04/2014 10:33, pratibha.dhankhar@wipro.com wrote:
> Hi All,
>
> Can anyone please suggest steps to remove vulnerability *OpenSSL "Heartbleed" Vulnerability <https://isc.sans.edu/forums/diary/+Patch+Now+OpenSSL+Heartbleed+Vulnerability/17921> *in apache.
>
> --
>
> Regards
>
> *Pratibha ***
>

You should first upgrade to openssl 1.0.1g, or at least patch your openssl version.

That should be enough for httpd if dynamically linked to opensssl.

If instead httpd is statically linked to open ssl then you shopuld rebuild httpd against openssl 1.0.1g.

Of course you should re-issue possibly stolen certicates as well.

See http://heartbleed.com/ for more information.

HTH,

Didier

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

[users@httpd] OpenSSL "Heartbleed" Vulnerability (was:Re: [users@httpd] Access control advice needed)

Posted by Didier Spaier <di...@epsm.fr>.

On 09/04/2014 10:33, pratibha.dhankhar@wipro.com wrote:
> Hi All,
>
> Can anyone please suggest steps to remove vulnerability *OpenSSL "Heartbleed" Vulnerability <https://isc.sans.edu/forums/diary/+Patch+Now+OpenSSL+Heartbleed+Vulnerability/17921> *in apache.
>
> --
>
> Regards
>
> *Pratibha ***
>

You should first upgrade to openssl 1.0.1g, or at least patch your openssl version.

That should be enough for httpd if dynamically linked to opensssl.

If instead httpd is statically linked to open ssl then you shopuld rebuild httpd against openssl 1.0.1g.

Of course you should re-issue possibly stolen certificates as well.

See http://heartbleed.com/ for more information.

HTH,

Didier

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

RE: [users@httpd] Access control advice needed

Posted by pr...@wipro.com.

Hi All,


Can anyone please suggest steps to remove vulnerability OpenSSL "Heartbleed" Vulnerability<https://isc.sans.edu/forums/diary/+Patch+Now+OpenSSL+Heartbleed+Vulnerability/17921> in apache.



--
Regards
Pratibha
From: Ramon Casha [mailto:ramon.casha@megabyte.net]
Sent: Wednesday, April 09, 2014 1:57 PM
To: users@httpd.apache.org
Subject: Re: [users@httpd] Access control advice needed

To be honest I don't want to end up having to maintain the IP blocks that correspond to the computers that are sending the requests, which is why I tried using the partial domain name. The apache documentation seems to suggest this would work:

A (partial) domain-name
Example:
Allow from apache.org
Allow from .net example.edu
The server is running Linux so I've got iptables but, again, I want to avoid having to maintain the list of blocked IP addresses.

The thing is, the methods I described would take care of the problems if I could get them to work - blocking all HTTP/1.0 requests to a specific location, and/or blocking everyone from that server.

I am currently working around it by adding a bit of PHP code to the drupal settings.php file but I'd like it to be tackled earlier than that - in apache's access control or iptables for instance.


On Erb, 2014-04-09 at 10:44 +0300, Oren wrote:
Hi Ramon.
Why use apache for the block and not a firewall? its not apache related but i think its a better way of doing that.
You can add those addresses to blocking rules and reduce the load on the apache before they even reach it.
I am not sure which os you use but there are simple ways of doing that even if you dont have dedicated hardware.

Oren
On 04/09/2014 10:32 AM, Jan Vávra wrote:
Hello,
 try to use an IP address or subnet instead of .broad.pt.fj.dynamic.163data.com.cn

Jan.
I have a website running drupal which is currently under a continuous
botnet attack, which is causing major performance issues. I'm trying to
use apache's access control mechanism to block these requests.

Two characteristics of the attack requests are that they all use
HTTP/1.0, and a large percentage of them are within one domain.

When I look at my access log, most requests are coming in from:
134.230.153.27.broad.pt.fj.dynamic.163data.com.cn
129.199.159.27.broad.pt.fj.dynamic.163data.com.cn
...etc.

i tried blocking access using Apache's Deny From as follows:

<Directory /opt/drupal-7/>
   Options +FollowSymLinks
   AllowOverride All
   Order Allow,Deny
   Allow from all
   Deny from .broad.pt.fj.dynamic.163data.com.cn
</Directory>

However this did not work - all requests are still being allowed in.
Note that the /opt/drupal-7 directory is a symlink to the actual
directory which has the full version number.

Also, since all the botnet requests are marked as HTTP/1.0, I tried to
restrict access to the user-registration pages using the protocol, as
follows:

SetEnvIf Request_Protocol "^HTTP/1\.0$" Bad_Req
<Location /utenti>
    Order Allow,Deny
    Deny from env=BadReq
</Location>

However this is blocking everything - HTTP/1.0 or 1.1. "/utenti" is the
prefix to the user registration page, password-reset page etc. I tried
changing around the Order, adding an "Allow from all" but in each case I
either end up blocking everyone or letting all requests through.

I'd appreciate any advice on how to implement the above or resolve this
issue in some other way.

--
Ramon Casha

Note: I have no control over the disclaimer message that will invariably
appear below.




DISCLAIMER

The information transmitted in this message and any attachments is strictly confidential and intended only for the individual or entity to whom it is addressed.
Any form of unauthorised review, transmission, disclosure, publication, reproduction, modification or other use of, or the taking of any action in reliance upon any of the information contained in this e-mail by individuals or entities other than the intended recipient is strictly prohibited.
If you are not the named addressee or the person responsible for delivering the message to the named addressee and have received this communication in error, you must not disclose the contents of this e-mail to any other person; or make any copies thereof. If you are not the named recipient please delete/destroy any and all copies that may exist, whether in electronic or hard copy for and notify us immediately on the phone number indicated above and provide us with details about the said e-mail received in error.
Since the Internet is not a secure medium Megabyte cannot guarantee the privacy or confidentiality of any e-mail communications transmitted. All messages sent to and from Megabyte Ltd may be monitored and/or recorded to ensure compliance with internal policies and procedures. We disclaim all responsibility and liability whatsoever in relation to any errors or omissions that may reveal themselves in this message and in relation to any damage that may result from any such errors or omissions. We disclaim all responsibility and liability for any damage that may arise from the unauthorised acts of third parties and/or the corruption of any data contained in this message.
Thank you.



--
________________________________


Ramon Casha | Technical Specialist | Software Services
megabyte ltd | e ramon.casha@megabyte.net<ma...@megabyte.net>
t + 356 21421600 | f + 356 21421590 | w www.megabyte.net<http://www.megabyte.net/>
________________________________


Please consider your environmental responsibility before printing this e-mail


DISCLAIMER

The information transmitted in this message and any attachments is strictly confidential and intended only for the individual or entity to whom it is addressed.
Any form of unauthorised review, transmission, disclosure, publication, reproduction, modification or other use of, or the taking of any action in reliance upon any of the information contained in this e-mail by individuals or entities other than the intended recipient is strictly prohibited.
If you are not the named addressee or the person responsible for delivering the message to the named addressee and have received this communication in error, you must not disclose the contents of this e-mail to any other person; or make any copies thereof. If you are not the named recipient please delete/destroy any and all copies that may exist, whether in electronic or hard copy for and notify us immediately on the phone number indicated above and provide us with details about the said e-mail received in error.
Since the Internet is not a secure medium Megabyte cannot guarantee the privacy or confidentiality of any e-mail communications transmitted. All messages sent to and from Megabyte Ltd may be monitored and/or recorded to ensure compliance with internal policies and procedures. We disclaim all responsibility and liability whatsoever in relation to any errors or omissions that may reveal themselves in this message and in relation to any damage that may result from any such errors or omissions. We disclaim all responsibility and liability for any damage that may arise from the unauthorised acts of third parties and/or the corruption of any data contained in this message.
Thank you.

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com

Re: [users@httpd] Access control advice needed

Posted by Vávra Jan <va...@602.cz>.

There could be a problem with reverse dns records. Eg. a hostname
www.example.com is translated to ip address x.x.x.x But if the Apache
Server asks what is the name of x.x.x.x adress, it could get nothing or  a
response www.somethingelse.com. So this could be your problem.

Jan.


2014-04-09 10:26 GMT+02:00 Ramon Casha <ra...@megabyte.net>:

>  To be honest I don't want to end up having to maintain the IP blocks
> that correspond to the computers that are sending the requests, which is
> why I tried using the partial domain name. The apache documentation seems
> to suggest this would work:
>
> A (partial) domain-name  *Example:* Allow from apache.org
> Allow from .net example.edu
> The server is running Linux so I've got iptables but, again, I want to
> avoid having to maintain the list of blocked IP addresses.
>
> The thing is, the methods I described would take care of the problems if I
> could get them to work - blocking all HTTP/1.0 requests to a specific
> location, and/or blocking everyone from that server.
>
> I am currently working around it by adding a bit of PHP code to the drupal
> settings.php file but I'd like it to be tackled earlier than that - in
> apache's access control or iptables for instance.
>
>
> On Erb, 2014-04-09 at 10:44 +0300, Oren wrote:
>
> Hi Ramon.
> Why use apache for the block and not a firewall? its not apache related
> but i think its a better way of doing that.
> You can add those addresses to blocking rules and reduce the load on the
> apache before they even reach it.
> I am not sure which os you use but there are simple ways of doing that
> even if you dont have dedicated hardware.
>
> Oren
>
>  On 04/09/2014 10:32 AM, Jan Vávra wrote:
>
>   Hello,
>  try to use an IP address or subnet instead of .
> broad.pt.fj.dynamic.163data.com.cn
>
> Jan.
>
>    I have a website running drupal which is currently under a continuous
> botnet attack, which is causing major performance issues. I'm trying to
> use apache's access control mechanism to block these requests.
>
> Two characteristics of the attack requests are that they all use
> HTTP/1.0, and a large percentage of them are within one domain.
>
> When I look at my access log, most requests are coming in from:
> 134.230.153.27.broad.pt.fj.dynamic.163data.com.cn
> 129.199.159.27.broad.pt.fj.dynamic.163data.com.cn
> ...etc.
>
> i tried blocking access using Apache's Deny From as follows:
>
> <Directory /opt/drupal-7/>
>    Options +FollowSymLinks
>    AllowOverride All
>    Order Allow,Deny
>    Allow from all
>    Deny from .broad.pt.fj.dynamic.163data.com.cn
> </Directory>
>
> However this did not work - all requests are still being allowed in.
> Note that the /opt/drupal-7 directory is a symlink to the actual
> directory which has the full version number.
>
> Also, since all the botnet requests are marked as HTTP/1.0, I tried to
> restrict access to the user-registration pages using the protocol, as
> follows:
>
> SetEnvIf Request_Protocol "^HTTP/1\.0$" Bad_Req
> <Location /utenti>
>     Order Allow,Deny
>     Deny from env=BadReq
> </Location>
>
> However this is blocking everything - HTTP/1.0 or 1.1. "/utenti" is the
> prefix to the user registration page, password-reset page etc. I tried
> changing around the Order, adding an "Allow from all" but in each case I
> either end up blocking everyone or letting all requests through.
>
> I'd appreciate any advice on how to implement the above or resolve this
> issue in some other way.
>
> --
> Ramon Casha
>
> Note: I have no control over the disclaimer message that will invariably
> appear below.
>
>
>
>
> *DISCLAIMER*
>
> *The information transmitted in this message and any attachments is
> strictly confidential and intended only for the individual or entity to
> whom it is addressed.*
> *Any form of unauthorised review, transmission, disclosure, publication,
> reproduction, modification or other use of, or the taking of any action in
> reliance upon any of the information contained in this e-mail by
> individuals or entities other than the intended recipient is strictly
> prohibited.*
> *If you are not the named addressee or the person responsible for
> delivering the message to the named addressee and have received this
> communication in error, you must not disclose the contents of this e-mail
> to any other person; or make any copies thereof. If you are not the named
> recipient please delete/destroy any and all copies that may exist, whether
> in electronic or hard copy for and notify us immediately on the phone
> number indicated above and provide us with details about the said e-mail
> received in error.*
> *Since the Internet is not a secure medium Megabyte cannot guarantee the
> privacy or confidentiality of any e-mail communications transmitted. All
> messages sent to and from Megabyte Ltd may be monitored and/or recorded to
> ensure compliance with internal policies and procedures. We disclaim all
> responsibility and liability whatsoever in relation to any errors or
> omissions that may reveal themselves in this message and in relation to any
> damage that may result from any such errors or omissions. We disclaim all
> responsibility and liability for any damage that may arise from the
> unauthorised acts of third parties and/or the corruption of any data
> contained in this message.*
> *Thank you.*
>
>
>
>
>   --
> ------------------------------
>
>
> *Ramon Casha* | Technical Specialist | Software Services
> *megabyte ltd* | *e* ramon.casha@megabyte.net
> *t* + 356 21421600 | *f* + 356 21421590 | *w* www.megabyte.net
> ------------------------------
>
>
> Please consider your environmental responsibility before printing this
> e-mail
>
>  *DISCLAIMER*
>
>
>
>
>
> *The information transmitted in this message and any attachments is
> strictly confidential and intended only for the individual or entity to
> whom it is addressed.Any form of unauthorised review, transmission,
> disclosure, publication, reproduction, modification or other use of, or the
> taking of any action in reliance upon any of the information contained in
> this e-mail by individuals or entities other than the intended recipient is
> strictly prohibited.If you are not the named addressee or the person
> responsible for delivering the message to the named addressee and have
> received this communication in error, you must not disclose the contents of
> this e-mail to any other person; or make any copies thereof. If you are not
> the named recipient please delete/destroy any and all copies that may
> exist, whether in electronic or hard copy for and notify us immediately on
> the phone number indicated above and provide us with details about the said
> e-mail received in error.Since the Internet is not a secure medium Megabyte
> cannot guarantee the privacy or confidentiality of any e-mail
> communications transmitted. All messages sent to and from Megabyte Ltd may
> be monitored and/or recorded to ensure compliance with internal policies
> and procedures. We disclaim all responsibility and liability whatsoever in
> relation to any errors or omissions that may reveal themselves in this
> message and in relation to any damage that may result from any such errors
> or omissions. We disclaim all responsibility and liability for any damage
> that may arise from the unauthorised acts of third parties and/or the
> corruption of any data contained in this message.Thank you.*
>
>  <#145459912488242d_>
>
>

Re: [users@httpd] Access control advice needed

Posted by Ramon Casha <ra...@megabyte.net>.

To be honest I don't want to end up having to maintain the IP blocks that correspond to the computers that are sending the requests, which is why I tried using the partial domain name. The apache documentation seems to suggest this would work:

A (partial) domain-name

Example:

Allow from apache.org
Allow from .net example.edu

The server is running Linux so I've got iptables but, again, I want to avoid having to maintain the list of blocked IP addresses.

The thing is, the methods I described would take care of the problems if I could get them to work - blocking all HTTP/1.0 requests to a specific location, and/or blocking everyone from that server.

I am currently working around it by adding a bit of PHP code to the drupal settings.php file but I'd like it to be tackled earlier than that - in apache's access control or iptables for instance.

On Erb, 2014-04-09 at 10:44 +0300, Oren wrote:

Hi Ramon.
Why use apache for the block and not a firewall? its not apache related but i think its a better way of doing that.
You can add those addresses to blocking rules and reduce the load on the apache before they even reach it.
I am not sure which os you use but there are simple ways of doing that even if you dont have dedicated hardware.

Oren

On 04/09/2014 10:32 AM, Jan Vávra wrote:

Hello,
try to use an IP address or subnet instead of .broad.pt.fj.dynamic.163data.com.cn

Jan.