On 27 Feb 2018, at 5:00 PM, William A Rowe Jr wrote:
> They had likely RTFM ... looking at
> https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html#remoteipproxyprotocol
>
> Compatibility:RemoteIPProxyProtocol is only available in httpd 2.4.28 and
> newer
Fixed in r1825468.
Regards,
Graham
—
or another method is simple copy .c file from 2.5/trunk and compile it with
2.4.30 using apxs. I did it and it's working fine
Thx
Marcin
Od: "Jacob Perkins"
Do: "dev"
Wysłane: wtorek, 27 luty 2018 16:23:07
Temat: Re: 2.4.29 || mod_remoteip w/RemoteIPProxyProt
;mailto:jacob.perk...@cpanel.net>> wrote:
>
>> I have a customer who’s attempting to use RemoteIPProxyProtocol with
>> mod_remoteIP. Per 2.4 documentation, this directive should be available (
>> https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html
>> <h
Jr wrote:
>
> On Tue, Feb 27, 2018 at 8:57 AM, Graham Leggett wrote:
>> On 27 Feb 2018, at 4:44 PM, Jacob Perkins wrote:
>>
>> I have a customer who’s attempting to use RemoteIPProxyProtocol with
>> mod_remoteIP. Per 2.4 documentation, this directive should be available
,
>
> I have a customer who’s attempting to use RemoteIPProxyProtocol with
> mod_remoteIP. Per 2.4 documentation, this directive should be available (
> https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html
> <https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html> )
&g
On Tue, Feb 27, 2018 at 8:57 AM, Graham Leggett wrote:
> On 27 Feb 2018, at 4:44 PM, Jacob Perkins wrote:
>
> I have a customer who’s attempting to use RemoteIPProxyProtocol with
> mod_remoteIP. Per 2.4 documentation, this directive should be available (
> https://httpd.apache.o
On 27 Feb 2018, at 4:44 PM, Jacob Perkins wrote:
> I have a customer who’s attempting to use RemoteIPProxyProtocol with
> mod_remoteIP. Per 2.4 documentation, this directive should be available (
> https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html
> <https://httpd.apac
Good morning,
I have a customer who’s attempting to use RemoteIPProxyProtocol with
mod_remoteIP. Per 2.4 documentation, this directive should be available (
https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html
<https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html> )
I built
I can see that a flat directive namespace has its drawbacks... ;-)
> Am 01.04.2017 um 19:12 schrieb Daniel Ruggeri :
>
>
> On 4/1/2017 11:18 AM, Yann Ylavic wrote:
>> Hi Daniel,
>>
>> On Sat, Apr 1, 2017 at 3:56 PM, Daniel Ruggeri wrote:
>>> I went with the directive name
>>> RemoteIPProxyProt
On 4/1/2017 11:18 AM, Yann Ylavic wrote:
> Hi Daniel,
>
> On Sat, Apr 1, 2017 at 3:56 PM, Daniel Ruggeri wrote:
>> I went with the directive name
>> RemoteIPProxyProtocolDisableHosts to align more with the fact that a
>> single host or range can be disabled.
> How about RemoteIPProxyProtocolExcep
Hi Daniel,
On Sat, Apr 1, 2017 at 3:56 PM, Daniel Ruggeri wrote:
> I went with the directive name
> RemoteIPProxyProtocolDisableHosts to align more with the fact that a
> single host or range can be disabled.
How about RemoteIPProxyProtocolExceptions since one can configure
either an IP or a net
Sorry for the top post. I've committed r1789800 which pulls out Optional
handling and adds the ability to disable based on source network. This
is more or less the code as it was donated, plus some cleanup and the
small addition to disable based on networks (overall a cleaner approach
anyway). I we
ng. I
hope to have a patch later this morning to share. As awful as the name
is, I'm thinking RemoteIPProxyProtocolDisableNetworks ARG1 ARG2 ARG3.
--
Daniel Ruggeri
On 3/29/2017 4:43 PM, William A Rowe Jr wrote:
> This is the gist of my remaining objections.
>
> It would be nice
On Wed, Mar 29, 2017 at 4:43 PM, William A Rowe Jr wrote:
>
> It would be nice if the mod_remoteip patch to PROXY protocol followed the
> security advisories of the PROXY draft security comments, and we rip out the
> 'optional' mode. The remaining objection is around the
gt;>>> wrote:
>>>>>>> On Wed, Feb 15, 2017 at 9:02 AM, Sander Hoentjen
>>>>>>> wrote:
>>>>>>>> mod_remote ip has:
>>>>>>>> /* mod_proxy creates outgoing connections - we don't want those */
>>>>>&g
e:
>>>>>>> mod_remote ip has:
>>>>>>> /* mod_proxy creates outgoing connections - we don't want those */
>>>>>>> if (!remoteip_is_server_port(c->local_addr->port)) {
>>>>>>> return DECLINED
't want those */
>>>>>> if (!remoteip_is_server_port(c->local_addr->port)) {
>>>>>> return DECLINED;
>>>>>> }
>>>>>> I am guessing something similar is needed for h2 connections?
>>>>>
addr->port)) {
>>>>> return DECLINED;
>>>>> }
>>>>> I am guessing something similar is needed for h2 connections?
>>>> I suspect that the mod_remoteip logic is wrong, that it should be guarding
>>>> against any subordi
>> /* mod_proxy creates outgoing connections - we don't want those */
>>>> if (!remoteip_is_server_port(c->local_addr->port)) {
>>>> return DECLINED;
>>>> }
>>>> I am guessing something similar is needed for h2 connec
- we don't want those */
>> > if (!remoteip_is_server_port(c->local_addr->port)) {
>> > return DECLINED;
>> > }
>> > I am guessing something similar is needed for h2 connections?
>>
>> I suspect that the mod_remoteip logic is wrong,
has:
> > > /* mod_proxy creates outgoing connections - we don't want those */
> > > if (!remoteip_is_server_port(c->local_addr->port)) {
> > > return DECLINED;
> > > }
> > > I am guessing something similar is needed for h2 c
l_addr->port)) {
> > return DECLINED;
> > }
> > I am guessing something similar is needed for h2 connections?
>
> I suspect that the mod_remoteip logic is wrong, that it should be guarding
> against any subordinate connections and examining only explicitly c
mething similar is needed for h2 connections?
I suspect that the mod_remoteip logic is wrong, that it should be guarding
against any subordinate connections and examining only explicitly configured
ports / origin IPs. the PROXY protocol is not part of the HTTP protocol and
incompatible with i
On 02/15/2017 12:19 PM, Jordan Gigov wrote:
> On 15 February 2017 at 12:50, Sander Hoentjen wrote:
>> Hey guys,
>>
>> I am trying to use both mod_remoteip with ProxyProtocol and mod_http2.
>> It looks like mod_http2 gets handed the connection before mod_remoteip,
>
Try modules/http2/h2_h2.c line 550 add "mod_remoteip.c" after "mod_ssl.c".
This reminds me since remoteip is being updated, maybe it should also
specify some before and after mods to avoid.
On 15 February 2017 at 12:50, Sander Hoentjen wrote:
> Hey guys,
>
> I am tr
Hey guys,
I am trying to use both mod_remoteip with ProxyProtocol and mod_http2.
It looks like mod_http2 gets handed the connection before mod_remoteip,
so things don't work as they should. ProxyProtocol should always be
handled first, since it is prepended to the stream. Any pointers to
whe
Am 04.08.2016 um 17:46 schrieb Yann Ylavic:
On Thu, Aug 4, 2016 at 3:30 PM, Rainer Jung wrote:
- apr_ipsubnet_create() has some logic, that for instance accepts "192.168"
as input with NULL mask_or_numbits and returns sub 192.168.0.0 and mask
255.255.0.0.
Hmm, indeed, but this looks buggy to
On Thu, Aug 4, 2016 at 3:30 PM, Rainer Jung wrote:
>
> - apr_ipsubnet_create() has some logic, that for instance accepts "192.168"
> as input with NULL mask_or_numbits and returns sub 192.168.0.0 and mask
> 255.255.0.0.
Hmm, indeed, but this looks buggy to me.
Shouldn't apr_ipsubnet_create() be f
Am 04.08.2016 um 13:36 schrieb Yann Ylavic:
On Thu, Aug 4, 2016 at 10:14 AM, Rainer Jung wrote:
Something like "RemoteIPLookups (On|Off|NNN)". "On" would be current
behavior, "Off" would be "No DNS and use connection IP if address is
invalid", "NNN" would be "No DNS and return status NNN if ad
On Thu, Aug 4, 2016 at 10:14 AM, Rainer Jung wrote:
>
> Something like "RemoteIPLookups (On|Off|NNN)". "On" would be current
> behavior, "Off" would be "No DNS and use connection IP if address is
> invalid", "NNN" would be "No DNS and return status NNN if address is
> invalid". Default "On" or "Of
Hi there,
I learned that mod_remoteip does IP address resolution including DNS
when it processes a token from the configured RemoteIPHeader. In the
observed case, two different customers using F5 load balancers had a
numeric IP address in the header which was followed without white space
or
Am 31.01.2014 12:17, schrieb Reindl Harald:
> Am 30.01.2014 18:47, schrieb Eric Covener:
>> I think a link here is good for posterity
>
> thanks again for feedback
>
> mod_rewrite doesn't expose client_addr
> https://issues.apache.org/bugzilla/show_bug.cgi?id=56094
https://issues.apache.org/bu
Am 30.01.2014 18:47, schrieb Eric Covener:
> I think a link here is good for posterity
thanks again for feedback
mod_rewrite doesn't expose client_addr
https://issues.apache.org/bugzilla/show_bug.cgi?id=56094
signature.asc
Description: OpenPGP digital signature
On Thu, Jan 30, 2014 at 11:25 AM, Reindl Harald wrote:
> should i post here the link to the bugreport or
I think a link here is good for posterity
he connection comes from a different IP mod_rewrite is supposed
>> to redirect the request as shown below to https
>>
>> without mod_remoteip the mod_rewrite snipped works as expected
>> so only a replacement for %{REMOTE_ADDR} would be needed that
>> us
d, but in case
> the connection comes from a different IP mod_rewrite is supposed
> to redirect the request as shown below to https
>
> without mod_remoteip the mod_rewrite snipped works as expected
> so only a replacement for %{REMOTE_ADDR} would be needed that
> uses the underly
e
the connection comes from a different IP mod_rewrite is supposed
to redirect the request as shown below to https
without mod_remoteip the mod_rewrite snipped works as expected
so only a replacement for %{REMOTE_ADDR} would be needed that
uses the underlying peer IP address of the connection
RemoteIPH
Viewing the patch as sent to the mailing list, points out unwanted tab
characters.
So I reattached a patch with these characters removed.
Thanks,
Mike Rumph
On 12/19/2013 10:46 AM, Mike Rumph wrote:
On 12/13/2013 5:03 PM, William A. Rowe Jr. wrote:
> There is nothing I see in the code that pr
On 12/13/2013 5:03 PM, William A. Rowe Jr. wrote:
> There is nothing I see in the code that prevents a cycle with internal
proxy from following a cycle with external proxy.
It's been several years so I was going from memory, but you are right...
> So if your explanation is the way the code is
that your patch is indeed valid and useful.
Since I am a relatively new developer (1 year) for the Apache httpd
project, I do not have committer access.
Perhaps there is a committer who is interested in mod_remoteip that will
consider committing the 54651 patch to trunk.
I will update bug 54651 to
included a RemoteIPProxiesHeader.
>>> But if it is included, the mod_remote documentation seems to indicate
>>> that the value should be different from the RemoteIPHeader.
>>> -
>>>
>>>http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html#remoteipproxi
tle error cases.
> Experiments to investigate this could take us outside the scope of the
> original bug reports, so I decided to discuss it here instead.
>
>
>
>> The setups so far have not included a RemoteIPProxiesHeader.
>>> But if it is included, the mod_remote
it is included, the mod_remote documentation seems to indicate
that the value should be different from the RemoteIPHeader.
-
http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html#remoteipproxiesheader
RemoteIPHeader X-Forwarded-For
RemoteIPProxiesHeader X-Forwarded-By
You are correct.
Fr
Not correct,
this is just a french man who didn't take time to check in a
dictionary... :)
I update...
Thx
CJ
Le 13/12/2013 19:57, Mike Rumph a écrit :
equivalant versus equivalent
Perhaps this is a difference in British versus American spelling,
correct?
Anyway, thanks for the commits
equivalant versus equivalent
Perhaps this is a difference in British versus American spelling, correct?
Anyway, thanks for the commits.
Mike Rumph
On 12/12/2013 10:12 PM, Christophe JAILLET wrote:
Trunk
=
r1550650 for comments upodate
r1550651 for redundant check
2.4.x
=
r1550652 for
Trunk
=
r1550650 for comments upodate
r1550651 for redundant check
2.4.x
=
r1550652 for comments upodate
The other one will be proposed for backport with other easy patches to
synch 2.4 and trunk in the coming days.
BTW, for someone who has write access to APR tree,
s/equivilant/equ
wrote:
While researching mod_remoteip to work on httpd bugs 55635 and 55637,
I noticed a few unrelated blemishes in mod_remoteip.c.
These include some redundant code and comment typos.
The attached patch against httpd trunk should address these.
Some comments below, but most importantly, you
and thought
were worth mentioning.
Mike Rumph
On 12/12/2013 9:34 AM, William A. Rowe Jr. wrote:
On Wed, 04 Dec 2013 11:25:32 -0800
Mike Rumph wrote:
While researching mod_remoteip to work on httpd bugs 55635 and 55637,
I noticed a few unrelated blemishes in mod_remoteip.c.
These include
On Thu, Dec 12, 2013 at 11:34 AM, William A. Rowe Jr.
wrote: On Wed, 04 Dec 2013 11:25:32 -0800
Mike Rumph wrote:
> > While researching mod_remoteip to work on httpd bugs 55635 and
> > I noticed a few unrelated blemishes in mod_remoteip.c.
> > These include some redundant code
On Wed, 04 Dec 2013 11:25:32 -0800
Mike Rumph wrote:
> While researching mod_remoteip to work on httpd bugs 55635 and 55637,
> I noticed a few unrelated blemishes in mod_remoteip.c.
> These include some redundant code and comment typos.
>
> The attached patch against httpd trunk
oteIPHeader.
> -
> http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html#remoteipproxiesheader
>
>
> RemoteIPHeader X-Forwarded-For
> RemoteIPProxiesHeader X-Forwarded-By
You are correct.
> From my analysis so far it appears that mod_remoteip is behaving as
> do
On Mon, 09 Dec 2013 19:52:35 +0100
Reindl Harald wrote:
>
> the mod_remoteip config looks like below
>
> RemoteIPHeader X-Forwarded-For
> RemoteIPProxiesHeader X-Forwarded-For
That config would be bad, and disagrees with the documentation.
The RemoteIPProxies
I forgot to add a [PATCH] tag on the front of the subject.
The changes here are minor, but they do make the code a little cleaner.
On 12/4/2013 11:25 AM, Mike Rumph wrote:
While researching mod_remoteip to work on httpd bugs 55635 and 55637,
I noticed a few unrelated blemishes in
documentation seems to indicate
that the value should be different from the RemoteIPHeader.
-
http://httpd.apache.org/docs/trunk/mod/mod_remoteip.html#remoteipproxiesheader
RemoteIPHeader X-Forwarded-For
RemoteIPProxiesHeader X-Forwarded-By
From my analysis so far it appears that mod_remoteip is
.apache.org/bugzilla/show_bug.cgi?id=55635
> >
> > any remoteip people able to look into this?
>
> i am willing to debug but i need a simplified
> step-to-step what to look for and how to
> reproduce if possible at all
>
> the mod_remoteip confi
> i am willing to debug but i need a simplified
> step-to-step what to look for and how to
> reproduce if possible at all
>
> the mod_remoteip config looks like below
>
> RemoteIPHeader X-Forwarded-For
> RemoteIPInternalProxy http://trafficserver.apache.org/>
&
to
reproduce if possible at all
the mod_remoteip config looks like below
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy http://trafficserver.apache.org/>
RemoteIPProxiesHeader X-Forwarded-For
signature.asc
Description: OpenPGP digital signature
This seems kinda serious
https://issues.apache.org/bugzilla/show_bug.cgi?id=55635
any remoteip people able to look into this?
While researching mod_remoteip to work on httpd bugs 55635 and 55637,
I noticed a few unrelated blemishes in mod_remoteip.c.
These include some redundant code and comment typos.
The attached patch against httpd trunk should address these.
Thanks,
Mike Rumph
Index: modules/metadata
can someone of http-upstream please help the mod_security developers
understand how to properly support mod_remoteip before Apache 2.6
comes out?
Original-Nachricht
Betreff: Re: [mod-security-users] Fwd: Availability of ModSecurity 2.7.3 >
mod_remoteip :-(
Datum: Mon, 06
>>> also a "%{c}a" to get the proxy's IP.
>>>
>>> That's rather confusing. Any opionions if the behavior should be
>>> changed or if this should be fixed by documentation?
>>
>> As soon as you enable mod_remoteip, you are in the worl
at's rather confusing. Any opionions if the behavior should be
>> changed or if this should be fixed by documentation?
>
> As soon as you enable mod_remoteip, you are in the world of proxies and load
> balancers, and by definition you have at least two ip addresses, the ad
his should be fixed by documentation?
As soon as you enable mod_remoteip, you are in the world of proxies and load
balancers, and by definition you have at least two ip addresses, the address of
the load balancer, and the address of the host beyond the load balancer.
It is up to the administ
Am 24.01.2013 21:02, schrieb Stefan Fritsch:
>> 10.0.0.103 - - [23/Jan/2013:17:01:53 +0100] "GET
>> /images/page/tidy_16.gif HTTP/1.1" 304 -
>> "http://www.test.rh:8080/"; "Mozilla/5.0 (X11; Linux x86_64;
>> rv:18.0) Gecko/20100101 Firefox/18.0" (-%)
>
>
> The problem seems to be ap_get_remote_
___
>>
>> BUT access-log contains the ip of the apache trafficserver
>> this is a major problem for replace mod_rafp with mod_remoteip
>> because webalizer-usages are more or less useless
>>
>> 10.0.0.103 - - [23/Jan/2013:17:01:53 +0100] &
PHP - fine, exactly how it should do:
> _SERVER["SERVER_ADDR"]10.0.0.99
> _SERVER["SERVER_PORT"]8080
> _SERVER["REMOTE_ADDR"]10.0.0.99
>
>
> BUT access-log contains the ip of the apache trafficserver
&g
hmpf - with "mod_rpaf" on httpd 2.4 the access-log-ip is correct
but the "REMOTE_ADDR" variable in PHP-scripts has the proxy-IP
means i can not upgrade production to 2.4 because "mod_remoteip"
will destory usages and "mod_rpaf" security because you have
i
however:
http://vova-zms.blogspot.co.at/2012/07/install-modrpaf-with-apache-24.html
patched "mod_rpaf" works with 2.4 but it would be really nice
to have EXACTLY it's behavior in "mod_remoteip" because i see
no way how i sell my customers chaning usages nor can i ch
"SERVER_PORT"] 8080
_SERVER["REMOTE_ADDR"] 10.0.0.99
BUT access-log contains the ip of the apache trafficserver
this is a major problem for replace mod_rafp with mod_remoteip
because webalizer-usages are more or less useless
10.0.0.103 - - [23/Ja
oring it in the next request isn't clean.
That seems entirely sensible, but other than "it feels dirty" did you
actually have any observations of a flaw?
> I do notice mod_remoteip can only be set server wide, and not per
> directory.
Of course - and that won't change
On 06 Feb 2010, at 2:30 AM, William A. Rowe Jr. wrote:
On 2/5/2010 4:35 PM, Graham Leggett wrote:
All of these modules, including mod_remoteip in trunk, take a piece
of
information from a request (a header value typically), and then
copies
the value upstream to the parent connection
On 2/5/2010 4:35 PM, Graham Leggett wrote:
>
> ideally there should be a value r->remote_ip, populated initially from
> connection->remote_ip, which a request can change at will, and that will
> go away when the request is finished. Modules that want to do access
> control, etc should rather look
On 2/5/2010 4:35 PM, Graham Leggett wrote:
> All of these modules, including mod_remoteip in trunk, take a piece of
> information from a request (a header value typically), and then copies
> the value upstream to the parent connection, blowing away the real value
> of the IP address.
Hi all,
Recently I have to deal with a number of modules that try to override
the r->connection->remote_ip value in order to use the IP address
originating from a load balancer, which obscures the real IP address
of the client.
All of these modules, including mod_remoteip in trunk
Colm MacCárthaigh wrote:
>
> I don't think permitting hostname/number is a good idea, because a
> hostname can map to multiple IPs, and it gets confusing, it's
> non-standard :-) Right now the code just does a single lookup, and uses
> that - so where there are multiple A/ records we'll have r
On Wed, Apr 1, 2009 at 12:45 AM, William A. Rowe, Jr.
wrote:
> I have essentially finished mod_remoteip at this point and am looking
> to find out the interest level of adopting this as a core module into
> trunk (modules/metadata/ appears to be the most appropriate targ
Graham Leggett wrote:
> William A. Rowe, Jr. wrote:
>
>> I have essentially finished mod_remoteip at this point and am looking
>> to find out the interest level of adopting this as a core module into
>> trunk (modules/metadata/ appears to be the most appropriate target)?
Graham Leggett wrote:
(Having not yet had a chance to look at the code) How is the possibility
of multiple IPs in the same header handled, eg:
X-Fowarded-For: 10.2.3.4, 10.11.12.13
I think you'll find your question is answered in the README I referenced.
It's handled fine. The interesting p
William A. Rowe, Jr. wrote:
I have essentially finished mod_remoteip at this point and am looking
to find out the interest level of adopting this as a core module into
trunk (modules/metadata/ appears to be the most appropriate target)?
+1.
I had to code up a similar feature recently in
I have essentially finished mod_remoteip at this point and am looking
to find out the interest level of adopting this as a core module into
trunk (modules/metadata/ appears to be the most appropriate target)?
mod_remoteip can deal with 2 situations effortlessly, one is the
absolute
80 matches
Mail list logo
