subject:"Finding the Apache httpd IP address when AJP is used"

Paul Klinkenberg wrote:

Hi Christopher,

Thanks for taking the time to respond; again much appreciated.

Your point, and André's, is understood. Security should not be done based on
incoming IP address.
With this current project, we off course want to deliver software which is
secure by default. Now, if someone would install Tomcat, then add the mod_cfml
valve, and then doesn't lock port 8080 or 8009, the server would become
vulnerable in the same way as if the /host-manager would not have
password-protection.

Currently, I am discussing with the main mod_cfml developers Jordan Michaels and Bilal Soylu how to implement security, since I now won't be implementing IP restriction. We'll probably go with using the secret configuration parameter for ajp like you suggested.
Or maybe using a shared secret key between the frontend server and the Tomcat valve. In this last case, we would also have tackled security when remote attackers try to contact Tomcat on http-8080 directly, instead of using the ajp connector.

I never knew the remote_addr could not be trusted, but I believe you at once
when you say so.
I thought it was taken from the actual socket connection. With the exception of
ajp by the way, where it is programmatically changed to reflect the remote
client while handling the http call. Out of curiosity, could you shed some
light as to why the remote_addr is not to be trusted in a regular http request?

Thanks again for your time and effort!

Kind regards,

Paul Klinkenberg

On Tomcat, you can set the AJP Connector to only listen on the local IP address of the
Tomcat server host. That means that only local LAN clients (including the httpd
front-end, presumably) can connect to that Connector.
So this already stops any external client (be it workstation or server) from even
connecting to Tomcat using AJP.
It also, presumably, insures that only your internal httpd front-ends can potentially
connect to Tomcat via AJP.

Now if you do not even trust your internal servers/clients, /then/ you need additional
measures. But in such a case, whether you use a secret which the front-end must provide,
or whether you use an additional header or Jk variable, is only a choice; but any of those
requires some setup on the front-ends.

The same is for the other Connectors, like HTTP/HTTPS. If you do not want people to
connect through these, disable them or have them also only listen on a local IP address.

Op 29 apr. 2015, om 17:48 heeft Christopher Schultz
ch...@christopherschultz.net het volgende geschreven:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Paul,

On 4/29/15 11:17 AM, Paul Klinkenberg wrote:

The reason I want to add the IP restriction in the valve, is to
make 100% sure that the request (for creating a new Tomcat context)
is indeed coming from the frontend webserver.

I think there are better ways to do this. Among them:

1. Firewall rule that only allows access to the AJP port from a
certain IP address/range.

2. Use of the secret configuration parameter for mod_jk/AJP connector

In production, we tunnel AJP from our web servers to our application
servers using stunnel, and stunnel connections are only allowed from
the range of IPs used by our web servers. Then, we actually have the
AJP connector listen on ::1 so nobody from the outside can connect to
us, except through such a tunnel.

This valve is a setup not just for me, where I could tweak server
settings and such, but for anyone who uses the mod_cfml connector.

It is installed by default by the Railo/Lucee installers
(getrailo.org http://getrailo.org/ / lucee.org
http://lucee.org/)

It seems a little fragile, because it requires configuration beyond
what an installer can auto-configure for you (i.e. it has no idea what
the IP address of the web server(s) is(are)).

Therefor, I cannot rely on an incoming header, as it could
originate from anywhere. Also, a remote system could call the AJP
endpoint on the Tomcat server, with this JkEnvVar set to a spoofed
value. (if the port is not firewalled off course) So the problem
with both options is, that they cannot be fully trusted.

If you are that paranoid, you also can't trust the source IP address
in the IP header, so you are back to square 1: you can't trust
anything, so don't build your security around this lack-of-trust.

If I am able to find out where the AJP request came from, then I
can validate the caller.

The only way to check the caller would be to get ahold of the Socket
that Tomcat is using to communicate. That's not easily done, since
Tomcat wants to protect its sockets from code messing-around with the
state of those Sockets.

If you don't trust mod_jk to send you the right values, then you also
can't trust the REMOTE_ADDR value that is pointing to the real
client. Basically, it comes down to this: you either trust mod_jk or
not. If you don't, then all bets are off.

If you *can* trust mod_jk, then just forward an environment variable
using JkEnvVar:

Re: Finding the Apache httpd IP address when AJP is used

Hi Christopher,

Thanks for taking the time to respond; again much appreciated.

Your point, and André's, is understood. Security should not be done based on 
incoming IP address.
With this current project, we off course want to deliver software which is 
secure by default. Now, if someone would install Tomcat, then add the mod_cfml 
valve, and then doesn't lock port 8080 or 8009, the server would become 
vulnerable in the same way as if the /host-manager would not have 
password-protection.

Currently, I am discussing with the main mod_cfml developers Jordan Michaels 
and Bilal Soylu how to implement security, since I now won't be implementing IP 
restriction. We'll probably go with using the secret configuration parameter 
for ajp like you suggested. 
Or maybe using a shared secret key between the frontend server and the Tomcat 
valve. In this last case, we would also have tackled security when remote 
attackers try to contact Tomcat on http-8080 directly, instead of using the ajp 
connector.

I never knew the remote_addr could not be trusted, but I believe you at once 
when you say so.
I thought it was taken from the actual socket connection. With the exception of 
ajp by the way, where it is programmatically changed to reflect the remote 
client while handling the http call. Out of curiosity, could you shed some 
light as to why the remote_addr is not to be trusted in a regular http request?

Thanks again for your time and effort!

Kind regards,

Paul Klinkenberg



 Op 29 apr. 2015, om 17:48 heeft Christopher Schultz 
 ch...@christopherschultz.net het volgende geschreven:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Paul,
 
 On 4/29/15 11:17 AM, Paul Klinkenberg wrote:
 The reason I want to add the IP restriction in the valve, is to
 make 100% sure that the request (for creating a new Tomcat context)
 is indeed coming from the frontend webserver.
 
 I think there are better ways to do this. Among them:
 
 1. Firewall rule that only allows access to the AJP port from a
 certain IP address/range.
 
 2. Use of the secret configuration parameter for mod_jk/AJP connector
 
 In production, we tunnel AJP from our web servers to our application
 servers using stunnel, and stunnel connections are only allowed from
 the range of IPs used by our web servers. Then, we actually have the
 AJP connector listen on ::1 so nobody from the outside can connect to
 us, except through such a tunnel.
 
 This valve is a setup not just for me, where I could tweak server 
 settings and such, but for anyone who uses the mod_cfml connector.
 It is installed by default by the Railo/Lucee installers
 (getrailo.org http://getrailo.org/ / lucee.org
 http://lucee.org/)
 
 It seems a little fragile, because it requires configuration beyond
 what an installer can auto-configure for you (i.e. it has no idea what
 the IP address of the web server(s) is(are)).
 
 Therefor, I cannot rely on an incoming header, as it could
 originate from anywhere. Also, a remote system could call the AJP
 endpoint on the Tomcat server, with this JkEnvVar set to a spoofed
 value. (if the port is not firewalled off course) So the problem
 with both options is, that they cannot be fully trusted.
 
 If you are that paranoid, you also can't trust the source IP address
 in the IP header, so you are back to square 1: you can't trust
 anything, so don't build your security around this lack-of-trust.
 
 If I am able to find out where the AJP request came from, then I
 can validate the caller.
 
 The only way to check the caller would be to get ahold of the Socket
 that Tomcat is using to communicate. That's not easily done, since
 Tomcat wants to protect its sockets from code messing-around with the
 state of those Sockets.
 
 If you don't trust mod_jk to send you the right values, then you also
 can't trust the REMOTE_ADDR value that is pointing to the real
 client. Basically, it comes down to this: you either trust mod_jk or
 not. If you don't, then all bets are off.
 
 If you *can* trust mod_jk, then just forward an environment variable
 using JkEnvVar: that technique can't be modified by the client
 injecting an HTTP header or anything like that. But of course, you
 still have to trust mod_jk and the connection the request came from.
 This is what the firewall should be used for, IMO.
 
 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2
 Comment: GPGTools - http://gpgtools.org
 
 iQIcBAEBCAAGBQJVQP1VAAoJEBzwKT+lPKRYkcwQAKEJ4L4xqd7h2TRoA0TaAZYk
 MsnpJy9fKSOB+18jAgN8d1vcctV9+zabgRqT+BhK6rArc3RcaO4puLgNe2k3IduH
 AMHXQARLyYFSH42q7cAFyiRV5jVhDdTKr+pEhKTNbXdwdoOxPQMknTpfK01ESPkA
 kVAKWnT2GdLq9eo3nSGlTXyKJrBLNPa2LhHHQXmc/VaSIO6wFR3pEP/DkoOdU430
 QVmDinvruNEvSSNf0ef8UTeBhLOYFb099GfIOFq57r46B5s63469yQCwRrCKK7c9
 g89Xm8j44TI445nj1J7BpbHfwLZxFsKRVwln2MZ0RKxX7ow/Zs/teQj7FpG6pbr2
 7RGPi7jn0bo5GVe15S8cQMhPt7144FwuO97dhzPPUD+Dqv6hXuuNO92uJbDjllCl
 GW5pzhHqKZ7BJ54q6RZsreArz/PRE+Cih/fs+MhjmHy6W/Aj5HeOVF8aJmn4/KvZ

Re: Finding the Apache httpd IP address when AJP is used

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 4/30/15 5:13 AM, André Warnier wrote:
 Paul Klinkenberg wrote:
 Hi Christopher,
 
 Thanks for taking the time to respond; again much appreciated.
 
 Your point, and André's, is understood. Security should not be
 done based on incoming IP address. With this current project, we
 off course want to deliver software which is secure by default.
 Now, if someone would install Tomcat, then add the mod_cfml
 valve, and then doesn't lock port 8080 or 8009, the server would
 become vulnerable in the same way as if the /host-manager would
 not have password-protection.
 
 Currently, I am discussing with the main mod_cfml developers
 Jordan Michaels and Bilal Soylu how to implement security, since
 I now won't be implementing IP restriction. We'll probably go
 with using the secret configuration parameter for ajp like you
 suggested. Or maybe using a shared secret key between the
 frontend server and the Tomcat valve. In this last case, we would
 also have tackled security when remote attackers try to contact
 Tomcat on http-8080 directly, instead of using the ajp
 connector.
 
 I never knew the remote_addr could not be trusted, but I believe
 you at once when you say so. I thought it was taken from the
 actual socket connection. With the exception of ajp by the way,
 where it is programmatically changed to reflect the remote client
 while handling the http call. Out of curiosity, could you shed
 some light as to why the remote_addr is not to be trusted in a
 regular http request?
 
 Thanks again for your time and effort!
 
 Kind regards,
 
 Paul Klinkenberg
 
 
 On Tomcat, you can set the AJP Connector to only listen on the
 local IP address of the Tomcat server host.  That means that only
 local LAN clients (including the httpd front-end, presumably) can
 connect to that Connector. So this already stops any external
 client (be it workstation or server) from even connecting to Tomcat
 using AJP. It also, presumably, insures that only your internal
 httpd front-ends can potentially connect to Tomcat via AJP.

Not quite. You can bind to localhost, which only allows local
connections. Or you can bind to * (all interfaces), which allows
connections from anywhere. Or, you can bind to a specific interface
(IP address), which also allows connections from anywhere. There is no
interface to which you can bind that means only the local network,
unless if course there is some other factor at work; such as an
interface that is only connected to a local network.

 Now if you do not even trust your internal servers/clients, /then/
 you need additional measures. But in such a case, whether you use a
 secret which the front-end must provide, or whether you use an
 additional header or Jk variable, is only a choice; but any of
 those requires some setup on the front-ends.

+1

 The same is for the other Connectors, like HTTP/HTTPS.  If you do
 not want people to connect through these, disable them or have them
 also only listen on a local IP address.

+1

The best way to protect against unauthorized access is to require
authentication in some way that doesn't rely on some shaky and sloppy
checking, like IP address.

At some point, you have to trust your own web servers. If you don't
trust your own web servers, it means you are expecting MitM attacks.
Why not lock-down the connections between your web servers and your
application servers and then not have to distrust incoming connections
just in case they aren't coming from your web servers?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVQjgBAAoJEBzwKT+lPKRYKEIP/1fAJwB2F99YVcgDbLPo9zky
aDRkX0Rvv73vVxJdWoOJsM1FsgGXBaPg83ZC383Ma9iKpI0E4+iLbSc3WNembMIr
PgV+6yG7BYV0p2v51OXOfzFNp3fDml6gc9RLEiQ+r8k5Dj7MscCHnKZzwaghxRyf
HBlSPy5k+TMrQsPEAIzx6mrM2r8VNVZjrisLXkatoviDGQG/9ji5q4OG6XVUv5pe
fSkWTpH04MZsEG/bRIqak1as0jQnjHckw+XH2aamApWRsIuH2HTV685BqSVOp3ZV
Cg1v0KXavJOjspWVPZpngDmTRaB4kvDt8pC2bbMUDxocZgw+SG/AwVY6IAvBpuPR
4oVB/vBGrY546lvjXxOvcr6RdNfs/+1pK6OFbaKcI5m4UxHVP1k8cRLCjRlcIKKX
MRWYraCwfx9CWd6t97Ax1FXge0fMgXPWobcgaGTRT7IKm0pSDAXbOvzwPPUxWFOP
aQ+nOIAp7He7kKsUEU/0DooV2Vzf+FVTNwW8z1rJMdPWd716OWS8ASUJi7yLVnOI
rH/O6TQ9gAhfUaAGY0nRtpAtPCCI05eUxWe91G+IFKIAvZ4O30Mi1AouwNo08CjZ
EBjpm7h67m5lkHQb/sVjCrMKcg70OnKEvjYbivgubf12HBrP89v1nTU/NE1fffD8
TuNP/MKIFBs6MzyrMh9H
=EBju
-END PGP SIGNATURE-

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

Re: Finding the Apache httpd IP address when AJP is used

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Paul,

On 4/30/15 3:24 AM, Paul Klinkenberg wrote:
 I never knew the remote_addr could not be trusted, but I believe
 you at once when you say so.
 
 I thought it was taken from the actual socket connection. With the 
 exception of ajp by the way, where it is programmatically changed
 to reflect the remote client while handling the http call. Out of 
 curiosity, could you shed some light as to why the remote_addr is
 not to be trusted in a regular http request?

The client can spoof the source IP in the packet headers.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVQjcQAAoJEBzwKT+lPKRY4HEP/30Lih3AbOBVh1fujyoB0fZd
tne7zc3bJnrhtwl3f5Je1YlLR+ij545HYlcRTeM6UFlh2k8N7rFTJIPdLlnbt4jC
62FPkmBYZQqtccgv/AP/E+jI75kstAW47LvL4UEOS0p/UwgW2phEN7Ko0SKvaHDk
YWj5/LrtCBfsZFLJeGqgcbU2c38BFdBZGS1zWgGgCuz53kH8y1LPKj7zgs0LuDOn
IHEFWVcXbUbHqcAS6Cfb6UV4kI1JiSTmtoufaqpcBOQtRG4lVMcrsK3660W8FMXC
DercNpofhYIX+E5B19FI1QlYl1dTd4Wz17QTMqsiK1T9qNG5JczYIHi3VX6KGwT9
oj5LO7K0v6E653gQBo+pcIJO6H44xOdg1J/U8rNuyTkfU2Vr+fMOA321kEchRYRj
Zb8J7DTtNuHAW5ncwH4YTqvEnbg2p9ZoF9tCB9330u3wdWsVCj/62WX6XT908ElD
hs2Z73qhdbm7REu8KPtk9WQkylNhptA6Uxe8ZPBD7jfxGPAR7KvpwwXPV2irhG/e
7Iq8SbmMK9zpI4W6oodjiv+olQmj8qo5tuSrpTbW264GSrioKVZ9jkclxfkzrtuf
utdotevKsCAOXQYzhtHcU6NkxUgvZZ76YOBmKBineEmb1ieXQzeQ0PgJdOHXVqpe
AYfiVawe60dkGrsKdr5R
=9bH5
-END PGP SIGNATURE-

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

Re: Finding the Apache httpd IP address when AJP is used

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Paul,

On 4/29/15 10:18 PM, l...@bsoft.com.cn wrote:
 p.s. I asked this question, in other wording, on SackOverflow.com
 http://sackoverflow.com/ as well. I hope I have better luck here
 ;-) 
 http://stackoverflow.com/questions/29858030/where-can-i-find-the-apach
e-httpd-server-ip-from-within-a-tomcat-valve-when-ajp
 http://stackoverflow.com/questions/29858030/where-can-i-find-the-apac
he-httpd-server-ip-from-within-a-tomcat-valve-when-ajp

It's
 
more clear from this post that you just want to make sure that
the HTTP (or AJP) request is coming from localhost.

If that's all you want, then change the Connector configuration so
that it's only listening on localhost, like this:

Connector address=127.0.0.1
 ...
 /

This will prevent any incoming connections from the outside world.

Does that solve your problem?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVQjiaAAoJEBzwKT+lPKRYyD0QAIS4KmX2osUNxLAd/taX9NP6
cHNaJnMgekgVNpvh5QpuGRO2e1ivMmheyBSo3lFtnK8kF++VIBZBpDqAZO/PUX1H
ubSo62ip6QCSSoonVKeWzrSFvDCN8xAb9R4FNRu+GbIV+ubiGfghYct+J0R1HXq0
1Ncm4SOpXjsYoOZDGK/AwMfoJDoN0QemvSuKp7ftASD0SCV4EOhZya6JCxLKMQte
dCtv+rfd0Q/qjVizDGdmCT3qqLHUMQ5eLy6dhveHny9vU5KT8ORfOrTZ6REmxnHe
pkhWFIv6hUPeSZw+kW4SlVQhBweet2bDfnso8zDkp65un9YRbUW+edSMTi8VD1aG
Z/AwjTXWjQF83+g6SY7asV6bcpGOFbYeRIVWB8NI14Z1rLLlicDPjJaD9EHYCM0q
jaoPNXprcQGrjFhcSCHBXjMdp6trK9es83+E8PeFJF9i5UTnWii2+k4GL05/MSxx
pysLFMiV4V14BOwR8yq7iWcMMzNxf7d6bCyYna4oHhsGfiqlJEKgg3AFyTPc+Ebb
+HOEqm+MkPFtM0TIsXhQBDvPu13SR0yTB894J/ns1PHLE7XlmBtgZ7+lPuRFINbQ
0eEWPKPoQGttkaibLRT7u3alLRPBUG4gqWUl0Ux16aOBdyJpTLoJsMm+cLYNgj0t
cuPcHfwY7LAVKjaQTKrU
=AsyJ
-END PGP SIGNATURE-

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

Re: Finding the Apache httpd IP address when AJP is used

Hi André,

 Paul Klinkenberg wrote:
 Hi Christopher,
 Thanks for taking the time to respond; again much appreciated.
 Your point, and André's, is understood. Security should not be done based on 
 incoming IP address.
 With this current project, we off course want to deliver software which is 
 secure by default. Now, if someone would install Tomcat, then add the 
 mod_cfml valve, and then doesn't lock port 8080 or 8009, the server would 
 become vulnerable in the same way as if the /host-manager would not have 
 password-protection.
 Currently, I am discussing with the main mod_cfml developers Jordan Michaels 
 and Bilal Soylu how to implement security, since I now won't be implementing 
 IP restriction. We'll probably go with using the secret configuration 
 parameter for ajp like you suggested. Or maybe using a shared secret key 
 between the frontend server and the Tomcat valve. In this last case, we 
 would also have tackled security when remote attackers try to contact Tomcat 
 on http-8080 directly, instead of using the ajp connector.
 I never knew the remote_addr could not be trusted, but I believe you at once 
 when you say so.
 I thought it was taken from the actual socket connection. With the exception 
 of ajp by the way, where it is programmatically changed to reflect the 
 remote client while handling the http call. Out of curiosity, could you shed 
 some light as to why the remote_addr is not to be trusted in a regular http 
 request?
 Thanks again for your time and effort!
 Kind regards,
 Paul Klinkenberg
 
 On Tomcat, you can set the AJP Connector to only listen on the local IP 
 address of the Tomcat server host.  That means that only local LAN clients 
 (including the httpd front-end, presumably) can connect to that Connector.
 So this already stops any external client (be it workstation or server) from 
 even connecting to Tomcat using AJP.
 It also, presumably, insures that only your internal httpd front-ends can 
 potentially connect to Tomcat via AJP.
 
 Now if you do not even trust your internal servers/clients, /then/ you need 
 additional measures. But in such a case, whether you use a secret which the 
 front-end must provide, or whether you use an additional header or Jk 
 variable, is only a choice; but any of those requires some setup on the 
 front-ends.
 
 The same is for the other Connectors, like HTTP/HTTPS.  If you do not want 
 people to connect through these, disable them or have them also only listen 
 on a local IP address.

Thanks for these tips. I see there are quite a few options to secure the AJP 
connector, which is great.

For the project I am currently working on, I have to take into consideration 
that the user might already have Tomcat installed, and then probably with the 
default configuration. That would mean the AJP connector is available, and http 
connector as well. When someone now wants to add the mod_cfml valve to their 
setup, I will warn them in the install/config notes to lock down their tomcat 
server, if they haven't done so already. Next to this, I would like to be able 
to make the valve secure by default, without having to rely on external 
settings.
For this secure by default, a required shared secret key seems like a 
solution to me. Remote users accessing either the http connector or ajp 
connector (only possible if the server is not firewalled), would need to have 
that key in order to get the valve to create a new context.

I _do_ trust the internal servers/clients, I just want to make sure that if a 
mod_cfml user was too lame to secure it's server, then mod_cfml isn't the 
weakest link to be able to hack the server. 
I hope that makes sense?

Kind regards,

Paul Klinkenberg





 Op 29 apr. 2015, om 17:48 heeft Christopher Schultz 
 ch...@christopherschultz.net het volgende geschreven:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Paul,
 
 On 4/29/15 11:17 AM, Paul Klinkenberg wrote:
 The reason I want to add the IP restriction in the valve, is to
 make 100% sure that the request (for creating a new Tomcat context)
 is indeed coming from the frontend webserver.
 I think there are better ways to do this. Among them:
 
 1. Firewall rule that only allows access to the AJP port from a
 certain IP address/range.
 
 2. Use of the secret configuration parameter for mod_jk/AJP connector
 
 In production, we tunnel AJP from our web servers to our application
 servers using stunnel, and stunnel connections are only allowed from
 the range of IPs used by our web servers. Then, we actually have the
 AJP connector listen on ::1 so nobody from the outside can connect to
 us, except through such a tunnel.
 
 This valve is a setup not just for me, where I could tweak server settings 
 and such, but for anyone who uses the mod_cfml connector.
 It is installed by default by the Railo/Lucee installers
 (getrailo.org http://getrailo.org/ / lucee.org
 http://lucee.org/)
 It seems a little fragile, because it requires configuration beyond
 what an

Re: Finding the Apache httpd IP address when AJP is used

Hi André,

 Paul Klinkenberg wrote:
 Hi André,
 Paul Klinkenberg wrote:
 Hi Christopher,
 Thanks for taking the time to respond; again much appreciated.
 Your point, and André's, is understood. Security should not be done based 
 on incoming IP address.
 With this current project, we off course want to deliver software which is 
 secure by default. Now, if someone would install Tomcat, then add the 
 mod_cfml valve, and then doesn't lock port 8080 or 8009, the server would 
 become vulnerable in the same way as if the /host-manager would not have 
 password-protection.
 Currently, I am discussing with the main mod_cfml developers Jordan 
 Michaels and Bilal Soylu how to implement security, since I now won't be 
 implementing IP restriction. We'll probably go with using the secret 
 configuration parameter for ajp like you suggested. Or maybe using a 
 shared secret key between the frontend server and the Tomcat valve. In 
 this last case, we would also have tackled security when remote attackers 
 try to contact Tomcat on http-8080 directly, instead of using the ajp 
 connector.
 I never knew the remote_addr could not be trusted, but I believe you at 
 once when you say so.
 I thought it was taken from the actual socket connection. With the 
 exception of ajp by the way, where it is programmatically changed to 
 reflect the remote client while handling the http call. Out of curiosity, 
 could you shed some light as to why the remote_addr is not to be trusted 
 in a regular http request?
 Thanks again for your time and effort!
 Kind regards,
 Paul Klinkenberg
 On Tomcat, you can set the AJP Connector to only listen on the local IP 
 address of the Tomcat server host.  That means that only local LAN 
 clients (including the httpd front-end, presumably) can connect to that 
 Connector.
 So this already stops any external client (be it workstation or server) 
 from even connecting to Tomcat using AJP.
 It also, presumably, insures that only your internal httpd front-ends can 
 potentially connect to Tomcat via AJP.
 
 Now if you do not even trust your internal servers/clients, /then/ you need 
 additional measures. But in such a case, whether you use a secret which 
 the front-end must provide, or whether you use an additional header or Jk 
 variable, is only a choice; but any of those requires some setup on the 
 front-ends.
 
 The same is for the other Connectors, like HTTP/HTTPS.  If you do not want 
 people to connect through these, disable them or have them also only listen 
 on a local IP address.
 Thanks for these tips. I see there are quite a few options to secure the AJP 
 connector, which is great.
 For the project I am currently working on, I have to take into consideration 
 that the user might already have Tomcat installed, and then probably with 
 the default configuration. That would mean the AJP connector is available, 
 and http connector as well. When someone now wants to add the mod_cfml valve 
 to their setup, I will warn them in the install/config notes to lock down 
 their tomcat server, if they haven't done so already. Next to this, I would 
 like to be able to make the valve secure by default, without having to 
 rely on external settings.
 For this secure by default, a required shared secret key seems like a 
 solution to me.
 
 Note : to check. I am not sure if the HTTP/HTTPS Connectors provide this 
 shared secret thing. This may well be an AJP Connector feature only.
 
 Remote users accessing either the http connector or ajp connector (only 
 possible if the server is not firewalled), would need to have that key in 
 order to get the valve to create a new context.
 I _do_ trust the internal servers/clients, I just want to make sure that if 
 a mod_cfml user was too lame to secure it's server, then mod_cfml isn't the 
 weakest link to be able to hack the server. I hope that makes sense?
 
 Ok, so at this point, you only want to know, by intellectual curiosity, *how 
 you could* theoretically, in your Valve, obtain the IP address and port of 
 the front-end proxy server who is forwarding the original client request to 
 your Tomcat.
 Oof, that was hard to write, and I hope it is correct.
 
 Actually, Christopher already provided the answer to that, in a previous post 
 :
 
  The only way to check the caller would be to get ahold of the Socket
  that Tomcat is using to communicate. That's not easily done, since
  Tomcat wants to protect its sockets from code messing-around with the
  state of those Sockets.
 
 That's a clue, but not a very helpful one for you, is it ?
 
 I believe that the main issue here is that there is no such standard 
 functionality dictated by the Servlet Specification, so there is no 
 obligation for any Servlet Engine to provide this, and apparently thus Tomcat 
 does not provide a way to obtain this information easily, because it doesn't 
 have to.
 And according to Christopher, there may even be a deliberate attempt from the 
 Tomcat code to prevent one

Re: Finding the Apache httpd IP address when AJP is used

Paul Klinkenberg wrote:

Hi André,

Paul Klinkenberg wrote:

Hi Christopher,
Thanks for taking the time to respond; again much appreciated.
Your point, and André's, is understood. Security should not be done based on
incoming IP address.
With this current project, we off course want to deliver software which is
secure by default. Now, if someone would install Tomcat, then add the mod_cfml
valve, and then doesn't lock port 8080 or 8009, the server would become
vulnerable in the same way as if the /host-manager would not have
password-protection.
Currently, I am discussing with the main mod_cfml developers Jordan Michaels and Bilal Soylu how to
implement security, since I now won't be implementing IP restriction. We'll probably go with using
the secret configuration parameter for ajp like you suggested. Or maybe using a shared
secret key between the frontend server and the Tomcat valve. In this last case, we
would also have tackled security when remote attackers try to contact Tomcat on http-8080 directly,
instead of using the ajp connector.
I never knew the remote_addr could not be trusted, but I believe you at once
when you say so.
I thought it was taken from the actual socket connection. With the exception of
ajp by the way, where it is programmatically changed to reflect the remote
client while handling the http call. Out of curiosity, could you shed some
light as to why the remote_addr is not to be trusted in a regular http request?
Thanks again for your time and effort!
Kind regards,
Paul Klinkenberg

On Tomcat, you can set the AJP Connector to only listen on the local IP address of the Tomcat
server host. That means that only local LAN clients (including the httpd
front-end, presumably) can connect to that Connector.
So this already stops any external client (be it workstation or server) from
even connecting to Tomcat using AJP.
It also, presumably, insures that only your internal httpd front-ends can
potentially connect to Tomcat via AJP.

Now if you do not even trust your internal servers/clients, /then/ you need additional
measures. But in such a case, whether you use a secret which the front-end
must provide, or whether you use an additional header or Jk variable, is only a choice;
but any of those requires some setup on the front-ends.

The same is for the other Connectors, like HTTP/HTTPS. If you do not want
people to connect through these, disable them or have them also only listen on
a local IP address.

Thanks for these tips. I see there are quite a few options to secure the AJP
connector, which is great.

For the project I am currently working on, I have to take into consideration that the
user might already have Tomcat installed, and then probably with the default
configuration. That would mean the AJP connector is available, and http connector as
well. When someone now wants to add the mod_cfml valve to their setup, I will warn them
in the install/config notes to lock down their tomcat server, if they haven't done so
already. Next to this, I would like to be able to make the valve secure by
default, without having to rely on external settings.
For this secure by default, a required shared secret key seems like a
solution to me.

Note : to check. I am not sure if the HTTP/HTTPS Connectors provide this shared secret
thing. This may well be an AJP Connector feature only.

Remote users accessing either the http connector or ajp connector (only possible if the
server is not firewalled), would need to have that key in order to get the valve to create
a new context.

I _do_ trust the internal servers/clients, I just want to make sure that if a mod_cfml user was too lame to secure it's server, then mod_cfml isn't the weakest link to be able to hack the server.
I hope that makes sense?

Ok, so at this point, you only want to know, by intellectual curiosity, *how you could*
theoretically, in your Valve, obtain the IP address and port of the front-end proxy server
who is forwarding the original client request to your Tomcat.

Oof, that was hard to write, and I hope it is correct.

Actually, Christopher already provided the answer to that, in a previous post :

That's a clue, but not a very helpful one for you, is it ?

I believe that the main issue here is that there is no such standard functionality
dictated by the Servlet Specification, so there is no obligation for any Servlet Engine to
provide this, and apparently thus Tomcat does not provide a way to obtain this information
easily, because it doesn't have to.
And according to Christopher, there may even be a deliberate attempt from the Tomcat code
to prevent one being able to do such things easily, because it could potentially mess up
things pretty badly if one

Re: [OT] Finding the Apache httpd IP address when AJP is used

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Paul,

On 4/30/15 3:24 AM, Paul Klinkenberg wrote:

I never knew the remote_addr could not be trusted, but I believe
you at once when you say so.

I thought it was taken from the actual socket connection. With the
exception of ajp by the way, where it is programmatically changed
to reflect the remote client while handling the http call. Out of
curiosity, could you shed some light as to why the remote_addr is

not to be trusted in a regular http request?

The client can spoof the source IP in the packet headers.

This is not on-topic, but since the point has been raised, and since there are many smart
people on this list..

I am probably not very clever in a hacking kind of way, but I have never been able to
figure out how a client could make use of this to actually achieve something with TCP.

Setting up a TCP connection requires a couple of packet exchanges *back and
forth*.
So, the client can indeed send a first SYN packet to a server, with a spoofed origin IP
address. But then the server would return the ACK packet to that spoofed IP address, which
is presumably not the real client's one, wouldn't it ?

What good would that be to the malevolent client ?
Unless the point is only to flood a server's TCP stack with connection requests which
never can get completed..

If anyone has a clue as to how this can be really exploited, I'm eager to learn.

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

Re: Finding the Apache httpd IP address when AJP is used

Paul Klinkenberg wrote:

Hi André,

Paul Klinkenberg wrote:

Hi André,

Paul Klinkenberg wrote:

On Tomcat, you can set the AJP Connector to only listen on the local IP address of the Tomcat
server host. That means that only local LAN clients (including the httpd
front-end, presumably) can connect to that Connector.
So this already stops any external client (be it workstation or server) from
even connecting to Tomcat using AJP.
It also, presumably, insures that only your internal httpd front-ends can
potentially connect to Tomcat via AJP.

Now if you do not even trust your internal servers/clients, /then/ you need additional
measures. But in such a case, whether you use a secret which the front-end
must provide, or whether you use an additional header or Jk variable, is only a choice;
but any of those requires some setup on the front-ends.

The same is for the other Connectors, like HTTP/HTTPS. If you do not want
people to connect through these, disable them or have them also only listen on
a local IP address.

Thanks for these tips. I see there are quite a few options to secure the AJP
connector, which is great.
For the project I am currently working on, I have to take into consideration that the
user might already have Tomcat installed, and then probably with the default
configuration. That would mean the AJP connector is available, and http connector as
well. When someone now wants to add the mod_cfml valve to their setup, I will warn them
in the install/config notes to lock down their tomcat server, if they haven't done so
already. Next to this, I would like to be able to make the valve secure by
default, without having to rely on external settings.
For this secure by default, a required shared secret key seems like a
solution to me.

Note : to check. I am not sure if the HTTP/HTTPS Connectors provide this shared
secret thing. This may well be an AJP Connector feature only.

Remote users accessing either the http connector or ajp connector (only
possible if the server is not firewalled), would need to have that key in order
to get the valve to create a new context.

I _do_ trust the internal servers/clients, I just want to make sure that if a
mod_cfml user was too lame to secure it's server, then mod_cfml isn't the
weakest link to be able to hack the server. I hope that makes sense?

Ok, so at this point, you only want to know, by intellectual curiosity, *how
you could* theoretically, in your Valve, obtain the IP address and port of the
front-end proxy server who is forwarding the original client request to your
Tomcat.
Oof, that was hard to write, and I hope it is correct.

Actually, Christopher already provided the answer to that, in a previous post :

That's a clue, but not a very helpful one for you, is it ?

I believe that the main issue here is that there is no such standard
functionality dictated by the Servlet Specification, so there is no obligation
for any Servlet Engine to provide this, and apparently thus Tomcat does not
provide a way to obtain this information easily, because it doesn't have to.
And according to Christopher, there may even be a deliberate attempt from the
Tomcat code to prevent one being able to do such things easily, because it
could potentially mess up

Re: Finding the Apache httpd IP address when AJP is used

Hi Christopher,

 Paul,
 
 On 4/29/15 10:18 PM, l...@bsoft.com.cn wrote:
 p.s. I asked this question, in other wording, on SackOverflow.com
 http://sackoverflow.com/ as well. I hope I have better luck here
 ;-) 
 http://stackoverflow.com/questions/29858030/where-can-i-find-the-apach
 e-httpd-server-ip-from-within-a-tomcat-valve-when-ajp
 http://stackoverflow.com/questions/29858030/where-can-i-find-the-apac
 he-httpd-server-ip-from-within-a-tomcat-valve-when-ajp
 
 It's more clear from this post that you just want to make sure that
 the HTTP (or AJP) request is coming from localhost.
 
 If that's all you want, then change the Connector configuration so
 that it's only listening on localhost, like this:
 
 Connector address=127.0.0.1
 ...
 /
 
 This will prevent any incoming connections from the outside world.
 
 Does that solve your problem?
 
 - -chris

On stackOverflow, I indeed said I (just) wanted to check for 
127.0.0.1/localhost. That was a simplification of the case, to keep the focus 
on getting the AJP request's source IP address.
In real life, there will also be setups where the source IP will be different. 
Sorry for any confusion this may have caused.

All in all, the SO question isn't really important anymore, since I now know 
that IP restriction wouldn't be the best way to accomplish the security I am 
looking for.
Personally, I'd still like to know the answer, but that's only because I have 
spent multiple hours trying to find that IP address from inside the valve ;)

Kind regards,

Paul Klinkenberg


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




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

Re: Finding the Apache httpd IP address when AJP is used