rejetto forum

Software => HFS ~ HTTP File Server => Topic started by: Andys on April 11, 2008, 07:07:04 AM

Title: Q / REQ : Proxied client IP detection
Post by: Andys on April 11, 2008, 07:07:04 AM
Hi, I have a question / feature wish.
Basically, some time ago I set up a Apache server, later decided that I want HFS to serve files. So I wanted both to be active and use port 80 (impossible in reality)
So, right now HFS works through Apache proxy and virtual host, everything is OK except all client IPs are 127.0.0.1 (localhost) because of proxy routing.

Is there a way to make HFS read client ip from "http_x_forwarded_for" in http request header? Or could you implement this option in later versions... very very please.

p.s. I stopped serving files through apache because of 'limit speed per ip' option in HFS. Very few file servers have it, and I really want it. And there's no module for apache-win32 that does it, the one and only mod_cband is for linux apache.
Title: Re: Q / REQ : Proxied client IP detection
Post by: Unknown8063 on April 11, 2008, 01:56:00 PM
Since I run a similar setup I will second this request.

One trick I found in Apache is to set the "ProxyPreserveHost On" directive.  This passes the correct hostname to HFS.  Perhaps there is a similar Apache directive for IP's?
Title: Re: Q / REQ : Proxied client IP detection
Post by: rejetto on April 11, 2008, 06:08:40 PM
This passes the correct hostname to HFS.  Perhaps there is a similar Apache directive for IP's?

it's impossible for apache to fake the IP.
hostname is possible instead.


about andys' request: it's not hard to make it, but... there's a security problem: how/when should i show the http_x_forwarded_for ?
the problem is about people trying to spoof their IP, to make HFS show an incorrect IP in the log.
Apache is a trusted source, but there's no way for HFS to know it's apache.
A safe way may be to show it instead of the IP, but only if the IP is 127.0.0.1, because we may assume that software running on your own PC is trusted.
Any opinion?
Title: Re: Q / REQ : Proxied client IP detection
Post by: Andys on April 12, 2008, 06:12:35 AM
the problem is about people trying to spoof their IP, to make HFS show an incorrect IP in the log.
Apache is a trusted source, but there's no way for HFS to know it's apache.
A safe way may be to show it instead of the IP, but only if the IP is 127.0.0.1, because we may assume that software running on your own PC is trusted.
Any opinion?

Any implementation of this option would be great, "connection from localhost" requirement will make it a little more secure.
Actually, I didn't even know about this header till two days ago, therefore never thought about spoofing issue.
Title: Re: Q / REQ : Proxied client IP detection
Post by: Unknown8063 on April 14, 2008, 03:02:40 PM
A safe way may be to show it instead of the IP, but only if the IP is 127.0.0.1, because we may assume that software running on your own PC is trusted.
Any opinion?

Sounds like a good solution.  However I use a VPN for the connection so be sure to allow us to specify the trusted IP.
Title: Re: Q / REQ : Proxied client IP detection
Post by: rejetto on April 16, 2008, 12:48:20 AM
i put this to my to-do-list

+ show header(http_x_forwarded_for) instead of IP, but only if IP in a customizable ip-mask (127.0.0.1 by default)
Title: Re: Q / REQ : Proxied client IP detection
Post by: cmatte on February 03, 2009, 07:00:11 PM
Hey,
any update on this?
I'm absolutely SURE I've read a post of you saying that "normal" proxied connections would give the correct ip into the HFS logs...and by normal, you meant NOT Stunnel as it's not a real http-proxy but encodes the whole TCP/IP traffic...lol this just to say I don't find it again ;D

The fact is that I believed into it and looked for something more like a http-proxy to use HFS protected by SSL.
Since I'm using Windows-7, I thought about IIS7 already integrated and went on with it. I created with it my own certificate, self-signed of course, and also very big like 8192 (there was the double too but I avoided ;D) and looked for a way to redirect traffic from the IIS7 working https protocol to HFS. I found it: it's a "RC" extension called Application Request Routing that together with URL Rewrite module now is set to correctly redirect traffic from https:443 to http HFS local port 8181.

Well, all this ""interesting"" story :D just to say I expected to see REAL IPs into HFS logs but...surprise...they're not there!!!! And I'm very disappointed mainly because I've had 2-3 hours of headache to correctly install IIS7 and mainly ARR with all its requirements (basically url rewrite which didn't install correctly into w-7 because of a bug...solved with a registry edit...you know those silly beta-software's bugs are made also by M$ hehehe).

I'd like to continue using this config as it is intersting and has much power ready to be used but mainly I simply wanted to use SSL and see IPs correctly...some hints? What kind of software did you mean with the post mentioned?

Thanks.
Matteo.

p.s. I've just noticed in the ARR there are two interesting options:
Preserve Client IP in the following header:
>X-Forwarded-For<
Forwarding proxy header value:
><
Everything into >< is editable...
Title: Re: Q / REQ : Proxied client IP detection
Post by: rejetto on February 04, 2009, 12:36:06 AM
your config is very interesting.
can you dump a request coming from the proxy, so we can see the header?
one of those you expect HFS to show the forwarded ip.
Title: Re: Q / REQ : Proxied client IP detection
Post by: cmatte on February 04, 2009, 02:51:28 PM
Mmh I didn't think about it...there's also a complete dump log, cool!
Well, just tried, here it is an example:
Code: [Select]
04/02/2009 15.06.24 Server stop
04/02/2009 15.06.25 Server start
04/02/2009 15.06.31 127.0.0.1:49539 Connected
04/02/2009 15.06.31 127.0.0.1:49539 Got 591 bytes
04/02/2009 15.06.31 127.0.0.1:49539 Requested GET /
04/02/2009 15.06.31 127.0.0.1:49539 Request dump
> GET / HTTP/1.1
> Connection: Keep-Alive
> Keep-Alive: 300
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Accept-Encoding: gzip,deflate
> Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
> Cookie: Volume=100
> Host: ********.ath.cx
> Max-Forwards: 10
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
> X-Original-URL: /
> X-Forwarded-For: 79.9.192.***:49538
> X-ARR-SSL: 0|128|CN=********.ath.cx|CN=********.ath.cx
> X-ARR-LOG-ID: 7bcb7281-a6a0-43d0-a1d2-15fa94a3613c
04/02/2009 15.06.31 127.0.0.1:49539 Sent 1460 bytes
04/02/2009 15.06.31 127.0.0.1:49539 Served 1.83 KB
04/02/2009 15.06.34 127.0.0.1:49539 Requested GET /favicon.ico
04/02/2009 15.06.34 127.0.0.1:49539 Request dump
> GET /favicon.ico HTTP/1.1
> Connection: Keep-Alive
> Keep-Alive: 300
> Accept: image/png,image/*;q=0.8,*/*;q=0.5
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Accept-Encoding: gzip,deflate
> Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
> Cookie: Volume=100
> Host: ********.ath.cx
> Max-Forwards: 10
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
> X-Original-URL: /favicon.ico
> X-Forwarded-For: 79.9.192.***:49538
> X-ARR-SSL: 0|128|CN=********.ath.cx|CN=********.ath.cx
> X-ARR-LOG-ID: 08f95bf5-cc95-4603-939e-7afe57cfbe4e
04/02/2009 15.06.34 127.0.0.1:49539 Sent 21875 bytes
04/02/2009 15.06.34 127.0.0.1:49539 Served 576 B
04/02/2009 15.06.37 127.0.0.1:49539 Got 1257 bytes
04/02/2009 15.06.37 127.0.0.1:49539 Requested GET /favicon.ico
04/02/2009 15.06.37 127.0.0.1:49539 Request dump
> GET /favicon.ico HTTP/1.1
> Connection: Keep-Alive
> Keep-Alive: 300
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Accept-Encoding: gzip,deflate
> Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
> Cookie: Volume=100
> Host: ********.ath.cx
> Max-Forwards: 10
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
> X-Original-URL: /favicon.ico
> X-Forwarded-For: 79.9.192.***:49542
> X-ARR-SSL: 0|128|CN=********.ath.cx|CN=********.ath.cx
> X-ARR-LOG-ID: 72db2f02-1fb7-41ef-b7c4-d98217292419
04/02/2009 15.06.37 127.0.0.1:49539 Sent 1152 bytes
04/02/2009 15.06.37 127.0.0.1:49539 Served 576 B
p.s. I hide personal informations (*s).
The interesting thing is also the X-ARR-LOG-ID part!
I've read on their website (they have an entire section in the IIS7 support forum for ARR only) they're working hard to make a "undefined" utility (could be an Apache extension or a module of IIS7 or a standalone application?) to make ARR interact with (for example) Apache server and, in particular, they want the Apache logs to contain real IPs(are there other things one could want to do!? don't think so...but you never know!)...I guess they're going to cross-check the LOG-ID for this!
Also, they say there's the functionality to achieve the same also with the current version...but seems the way is a bit abrupt (guess we'd need to use the console, like I needed to specify the personalized port of HFS)!

Anyway...WOW! The IP is there already, available to HFS ;D Now, how to change the IP HFS logs, 'securely'? I mean, as I read somewhere else in the forum, you spoke about the possibility a client would send its own "X-Forwarded-For" part that could make the system log the wrong IP!
BUT...since with ARR the "name" of the specify is editable...and, correct me if I'm wrong, the client doesn't even see the specifies added by ARR and sent to HFS, why not just use a brand new name and let ARR send it, I don't know, ARR-HFS-Forwarded-For for example ;D
Let me know what you think, and thanks for the help  ;)
Title: Re: Q / REQ : Proxied client IP detection
Post by: cmatte on February 07, 2009, 04:13:47 PM
Mm...what's up?No chance to get this done...one day? :'(
Title: Re: Q / REQ : Proxied client IP detection
Post by: rejetto on February 07, 2009, 05:37:28 PM
relax :)
i can't work on HFS every day :(

i found the problem. it's an HFS bug.

it has to do with the :PORT included in the x-forwarded-for field.
it was not supported. it will be in next build.

i will actually discard it, and keep showing the port of the socket your IIS will open to HFS.
i don't think this is important.
i can only think of a possible drawback: if you want to cross-check your logs, IIS and HFS, and you need to refer to the port number.

anyway, if we find it is important, i will make the forwarded port to be displayed instead of the real one.
Title: Re: Q / REQ : Proxied client IP detection
Post by: cmatte on February 07, 2009, 05:48:12 PM
Oh, don't worry, didn't want to say anything similar!!
I only didn't understand if you are willing to implement this or not, and I deducted the answer was no.
Instead, your solution is ok, I don't think the internal communication port could be useful in any environment!
Thanks for your [free!] work for us!!!

[p.s. in italiano me sa che me spiegavo meglio e non facevo queste figure hehehe....grazie davvero e scusa se sono sembrato scorbutico o pretenzioso, non volevo assolutamente!! Ci sentiamo...buon sabato sera...spero non avrai modo nemmeno di pensare ad HFS fino ALMENO a lunedì hehehe ;)]
Title: Re: Q / REQ : Proxied client IP detection
Post by: deutschlandlieben on February 18, 2020, 07:38:59 AM
Sounds like a good solution.  However I use a VPN for the connection so be sure to allow us to specify the trusted IP.
are VPNs IP trusted? I mean, it's quite obvious when you are using a VPN or no? I mean, https://vpnpro.com/vpn-solutions/why-does-netflix-block-my-vpn/ (https://vpnpro.com/vpn-solutions/why-does-netflix-block-my-vpn/) Netflix detects a VPN IP always, and bans it . So how it can be trusted?