Re: [users@httpd] blacklisting

[Marc Serra]

We are using a border firewall too. This firewall includes an option to
auto update "list of bad IP" from a proprietary database.

Also you can use a public bad IP list, for example:
https://feodotracker.abuse.ch/blocklist/ or
https://github.com/mlsecproject/combine/wiki/Threat-Intelligence-Feeds-Gathered-by-Combine,
and create a crontab script to parse this list and update your .htaccess
file

Missatge de Jim Albert  del dia dj., 17 de juny 2021 a
les 3:30:

> On 6/16/2021 9:05 PM, Will Fatherley wrote:
> > Hi All,
> >
> > I have been using A2 for a few years now, but I've not really needed
> > to implement any deny/black-listing because I simply have no
> > meaningful security/traffic constraints. In moving forward with
> > development on top of A2 which does have security implications, I'm
> > hoping it might be possible that folks might be willing to share how
> > they store blocked remote addresses. For instance, are relational
> > datastores and other such objects typically required at the enterprise
> > level to store blocked addresses? Or is a plaintext file suitable from
> > an efficiency standpoint?
> >
> > Best,
> > Will F
>
> I find it easiest to implement blocks at the border firewall especially
> if I'm implementing a stored list of known attack IP addresses. At the
> border firewall I can easily block a set of IP addresses from the WAN to
> all my resources... httpd and others.
>
> Within Apache there are a variety of examples of what you can do at:
> https://httpd.apache.org/docs/2.4/howto/access.html
>
> I'm sure others can add to this advice from their own experiences.
>
> Jim
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>
>

-- 
Marc Serra
Organització i Sistemes

-- 

   
  


 
  

  
  
  
 
 Manxa 1876, S.L.
Ctra. Les Tries, 
85.17800 Olot (Girona)
*Tel. 972 27 45 30 www.manxa.com 
* 
_ *Manxa Industrial 
*
_ *Manxa Ferros 
*
_ *Manxa Ferreteria i Parament de la Llar 
*___
  

  




-- 

Manxa 
1876, S.L. *
Ctra. 
Les Tries, 85. 17800 Olot (Girona)**Tel. 972 27 
45 30 Fax 972 27 45 32*


* Manxa Industrial | *Coneix
més aquí 




* Manxa Ferros | *Coneix
més aquí 




* Manxa Ferreteria i Parament de la Llar | 
*Coneix
més aquí 


**

-- 


El contingut d’aquest correu electrònic i els seus annexos és 
estrictament confidencial. En el cas que no siguis el destinatari i hagis 
rebut aquest missatge per error, preguem que ho comuniquis al remitent i 
procedeixis a la seva eliminació, sense difondre, emmagatzemar o copiar el 
seu contingut. Imprimeix aquest correu només si és necessari.

El contenido 
de este correo electrónico y sus anexos es estrictamente confidencial. En 
el caso de que no seas el destinatario y hayas recibido este mensaje por 
error, rogamos lo comuniques al remitente y procedas a su eliminación, sin 
difundir, almacenar o copiar su contenido. Imprimir este correo solo si es 
necesario.

The content of this email and its attachments is strictly 
confidential. If you are not the recipient and you have received this 
message by mistake, please notify the sender and proceed to its 
elimination, without spreading, storing or copying its content. Print this 
email only if necessary.

Le contenu de cet e-mail et de ses pièces jointes 
est strictement confidentiel. Dans le cas où vous n'êtes pas le 
destinataire et avez reçu ce message par erreur, veuillez en informer 
l'expéditeur et procéder à sa suppression, sans diffuser, stocker ou copier 
son contenu. Imprimez cet e-mail uniquement si nécessaire.

Re: [users@httpd] blacklisting

[Jim Albert]

On 6/16/2021 9:05 PM, Will Fatherley wrote:

Hi All,

I have been using A2 for a few years now, but I've not really needed 
to implement any deny/black-listing because I simply have no 
meaningful security/traffic constraints. In moving forward with 
development on top of A2 which does have security implications, I'm 
hoping it might be possible that folks might be willing to share how 
they store blocked remote addresses. For instance, are relational 
datastores and other such objects typically required at the enterprise 
level to store blocked addresses? Or is a plaintext file suitable from 
an efficiency standpoint?


Best,
Will F


I find it easiest to implement blocks at the border firewall especially 
if I'm implementing a stored list of known attack IP addresses. At the 
border firewall I can easily block a set of IP addresses from the WAN to 
all my resources... httpd and others.


Within Apache there are a variety of examples of what you can do at:
https://httpd.apache.org/docs/2.4/howto/access.html

I'm sure others can add to this advice from their own experiences.

Jim


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

[users@httpd] blacklisting

[Will Fatherley]

Hi All,

I have been using A2 for a few years now, but I've not really needed to
implement any deny/black-listing because I simply have no meaningful
security/traffic constraints. In moving forward with development on top of
A2 which does have security implications, I'm hoping it might be possible
that folks might be willing to share how they store blocked remote
addresses. For instance, are relational datastores and other such objects
typically required at the enterprise level to store blocked addresses? Or
is a plaintext file suitable from an efficiency standpoint?

Best,
Will F

Re: [users@httpd] Bug in mod_proxy_balancer or just a bad configuration?

[Nick Folino]

Any thoughts on this before I post a bug report?

On Tue, Jun 15, 2021 at 9:07 PM Nick Folino  wrote:

> So I changed the config to eliminate the order question:
>
> 
> Header add Set-Cookie "RZROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/"
> env=BALANCER_ROUTE_CHANGED
> BalancerMember http://www.google.com route=01
> BalancerMember http://www.yahoo.com route=02
> ProxySet stickysession=RZROUTEID
> 
> 
> Header add Set-Cookie "RZ2ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/"
> env=BALANCER_ROUTE_CHANGED
> BalancerMember http://www.fox.com  route=03
> BalancerMember http://www.cnn.com  route=04
> ProxySet stickysession=RZ2ROUTEID
> 
>
> ProxyPass "/goog"  "balancer://rz/"
> ProxyPassReverse "/goog"  "balancer://rz/"
> ProxyPass "/good"  "balancer://rz2/"
> ProxyPassReverse "/good"  "balancer://rz2/"
>
> going to http://myserver/goog redirects to the Google page and a
> set-cookie RZROUTEID=.01
> going to http://myserver/good redirects to Fox and a
> set-cookie RZ2ROUTEID=.03 and a second set-cookie for RZROUTEID=.03
>
> going back to http://myserver/goog redirects to Yahoo and dets a
> set-cookie RZROUTEID=.02
>
> Nick
>
> On Tue, Jun 15, 2021 at 7:57 PM Nick Folino  wrote:
>
>> I thought that too, but if the rz proxypass was catching all traffic for
>> rz2, then I wouldn't expect any traffic to get to rz2.
>> But traffic does go to rz2 and all of that works, except it resets the rz
>> route cookie.
>>
>> On Tue, Jun 15, 2021 at 3:27 PM Daniel Ferradal 
>> wrote:
>>
>>> If I am looking at it correctly the order of the ProxyPass directives
>>> you defined is not the correct one, /sz defined first would be overriding
>>> /sz2. So sz2 should be defined first.
>>>
>>> Perhaps that's why you are getting wrong values ? (Browser cache or
>>> similar?)
>>>
>>> El mar., 15 jun. 2021 19:00, Nick Folino  escribió:
>>>
 I ran into an interesting situation with cookies being reset
 in balancers.
 I couldn't find any documentation on whether numbers are allowed in
 balancer names.

 I have this config:


   Header add Set-Cookie "RZROUTEID=.%{BALANCER_WORKER_ROUTE}e;
 path=/" env=BALANCER_ROUTE_CHANGED
   BalancerMember ajp://server1 route=01
   BalancerMember ajp://server2 route=02
   ProxySet stickysession=RZROUTEID



   Header add Set-Cookie "RZ2ROUTEID=.%{BALANCER_WORKER_ROUTE}e;
 path=/" env=BALANCER_ROUTE_CHANGED
   BalancerMember ajp://server3 route=03
   BalancerMember ajp://server4 route=04
   ProxySet stickysession=RZ2ROUTEID


 ProxyPass /rz balancer://rz/rz
 ProxyPass /rz2 balancer://rz2/rz2


 All works as expected when going to http://myhost/rz
 I get the RZROUTEID cookie set to 01 or 02 on first hit and it stays
 set.

 If I then go to http://myhost/rz2 I get the RZ2ROUTEID set to 03 or 04
 but also another cookie set for RZROUTE with the same value as the
 RZ2ROUTEID cookie.

 This causes an issue when going back to /rz as the RZROUTEID cookie is
 now invalid and gets reset based on the balancing rules.

 I solved the problem by renaming the rz2 balancer to a new name with a
 digit.
 Is this by design that digits cause problems in balancer names?  or is
 this a bug?

 Nick