IP address normalization
ilo - March 17, 2009 - 07:27
| Project: | Login Security |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
Description
Currently, ip addresses are being handled as raw strings. To efectively consider ipv4 and ipv6 in bruteforce operations, and to avoid x-forwarded-for tricks when a reverse proxy is in use, the ip addresses should be normalized.
Subtask of #397890: create a stable version for the 6.x branch of the login_security module
#1
I'd help on this, but it's not clear on what exactly you mean by "normalize".
#2
Thanks deekayen, somehow you have boosted the issue queue. Currently I'm thinking about saving IP address as int instead of string, due to ipv6 and ipv4 conversion issues. The problem is that using a proxy IP address can be forged and networks supporting both addressing could misuse the number of allowed attempts. AFAIK there could be three possible addresses for the same IP address in mixed environments, so I'm dealing with a ipv4/ipv6 > to > db long and do integer comparations.
192.168.1.10 = fe80:0:0:0:0:0:c0a8:10a = fe80::c0a8:10a = fe80::192.168.1.10 = ::ffff:192.168.1.10
I know it depends in the server and network configuration, but somehow I don't feel this is consistent.
I've the functions for the conversion and I'm testing them, but have all this in other location. I'll post it here when I get back them.
#3
troll module uses ip2long, but I don't remember how that handles ipv6. It could be a start to use that as a phase 1, and then patch it again to get ipv6 with a custom rolled function if need be. there are a couple examples on http://php.net/ip2long comments.
#4
I saw it, but I'm dealing with a generic approach for ipv4 and ipv6 support from the begining. "ip2long — Converts a string containing an (IPv4) Internet Protocol dotted address into a proper address" will never work for ipv6, and inet_pton should be used.
The bad part is that inet_pton supporting ipv6 is not available if PHP < 5.1.0 or php is not compiled with ipv6 support.
The good part is that there is a compat version of inet_pton and inet_ntop that should work on any php (since PHP 4.2.0) and we may include safely (attached).
My intention is to first, convert all ip addresses to ipv6 internally (we should not care about the value as it's not being shown anywhere) and then we can compare all of them. The problem I'm currently trying to solve is how to deal with host ban rules.
The file includes some functs and references.. I'm just testing this.
#5
@ilo: This is all yours to run with.
#6
I will not focus on this for now, so I'll postpone it
#7
I don't follow your example. ::ffff:192.168.1.10 is the v4-mapped version of 192.168.1.10, but where do fe80:0:0:0:0:0:c0a8:10a, fe80::c0a8:10a, fe80::192.168.1.10 come from? Those are link-local addresses.
#8
I'm trying to find a way to store ip addresses no matter if they are ipv4 or ipv6, so there can't be spoofed requests in mixed (ipv6 with ipv4 support) networks, and trying to find a way that doesn't fail.
All the ipv6 addresses (compacted or not) I posted would match the same ipv4 address if they are converted using any of the conversion tools I have found, for example this one: http://www.subnetonline.com/pages/subnet-calculators/ipv4-to-ipv6-conver... .
Just noticing this multiple match to don't forget it.
edit: english corrections
#9
I still don't follow. Aside from v4-mapped addresses (which are a special case), you can't convert an IPv4 address into an IPv6 address.
#10
and actually I don't try to do this.
from #2: so I'm dealing with a ipv4/ipv6 > to > db long and do integer comparations.
it's ipv4 or ipv6 to the same object, instead of having different object types for different ip address spaces (currently ipv4 is long and ipv6 y double long). The idea is to handle db long field to do integer matches between ip address instead of string comparations. So first I proposed to do a v4-mapped conversion of ipv4 within ipv6 notation, and then do the db long conversion.
Did you review the code attached in the issue? did you find it suitable for the purpose?
#11
The code is returning odd results for me.
I'm not sure why you included examples with link-local addresses (the fe80::/64 examples). You have several tests with link-local addresses with what appear to be embedded IPv4 addresses, except that link-locals can't have embedded IPv4 addresses (e.g., print_r((IPv6ToLong('fe80::192.168.1.1',0));, That is an invalid IPv6 address.)
When I run the test (IPv6ToLong('::ffff:192.168.1.1') == IPv6ToLong(IPv4TO6('192.168.1.1')), I get a failure. This seems to indicate that the conversion functions aren't working properly.
#12
I agree with you that code is not working, and the idea should be focused a little bit for things to be clear. I guess, these were also the reasons why this is an issue.. would I say..
:)