I have an existing php web application, I'm on IPv4, how can I fake IPv6 address to test the application compatibility with it? or is there a better way to test IPv6 compatibility?
Update:
My application log the ip of the user when he's making certain actions. The IP addresses are stored in the database (from another question I can understand that BINARY is the best column type). The application should also be possible to search by IP.
I want apache / php to work as if I were using IPv6, I need to be sure my application compatibility with IPv6 is ready for production on both IPv4 networks + IPv6 networks.
I agree with Topener; don't worry about it, your website will run fine with IPv6.
You don't need to worry about apache or PHP either, they will run fine.
You should only care about storing IPv6 addresses in a database etc.
Make sure you can store them in a proper way and that your database can handle an IPv6 address.
You can simply change $_SERVER['REMOTE_ADDR'] to an IPv6 address:
echo $_SERVER['REMOTE_ADDR']; // will give you your current IP (probaply IPv4)
// change the REMOTE_ADDR to an IPv6 address
$_SERVER['REMOTE_ADDR'] = '3ffe:6a88:85a3:08d3:1319:8a2e:0370:7344';
You can find additional information about storing IPv6 addresses into a database here:
How to store IPv6-compatible address in a relational database
Your website will run fine with IPv6. The only thing you need to test is, if you are storing IPv6, or logging of some kind, you should store it properly. To fake this, just enter some variable and put it to the database, or whatever you want to do with it.
An example: 2001:db8::1:0:0:1 and 2001:0DB8:0:0:1::1 and fe80::202:b3ff:fe1e:8329
Otherwise, don't worry about it!
If your application logs IP addresses then make sure that the fields to store them are big enough. Make sure that any application that processes those logs knows how to deal with IPv6 addresses. If you need to search for addresses by block/range you should use appropriate storage types for that. If you do access control based on IP address then it becomes a bit more difficult because IPv6 clients might change their source address often when they have privacy extensions enabled, so you might want to allow access per /64 instead of per separate address.
And most important: test, test, test :-)
Also note that for comparing IPv6 adresses, string comparison is not enough. There are different representations of the same IP adress, for example 2001:0DB8:0:0:1::1 is the short form of 2001:0db8:0000:0000:0001:0000:0000:0001.
Related
I am running into an issue in relation to security and verification. I have a software that checks to confirm a user, and I need to make sure it's the same client sending a PHP request and a node server request. However, on the node server, the client's IP is shown in IPv4, and on the PHP it is shown in IPv6. Is there any way I can get the same output somewhere, for example extract the IPv6 on the node server, or the IPv4 on the PHP server? Thanks.
Obtaining the same IP or verifying that it is the same client despite a "different" IPv4 and IPv6
The problem is that IPv6 and IPv4 are not coupled in any way. There's no way to deduce a v6 address from the v4 address or the other way around.
In my humble opionion, verifying users by their IP addresses is something you should avoid as IP addresses are spoofable, and the practice leads to these kind of issues. That said, there are a couple of "solutions".
Disable IPv6 on the webserver that's hosting the PHP application. Since you haven't mentioned which type of webserver this is, you should be able to google something like 'disable ipv6 apache' on how to achieve this. This should garantuee an identical IPv4 address on both servers. I personally don't particularly like this solution as it hinders IPv6 adoption.
Enable IPv6 on the node server. Please note that clients can still prefer IPv4 over IPv6 for any reason at all and there's no way to garantuee that it will use IPv6 to both webservers.
You could proxy all calls from one webserver to the other and pass the original IP in for example an 'X-Forwarded-For' header. This will introduce some overhead, but the source IP will be stabler.
Personally, I'd shy away from using the IP address and implement some sort of token stored on the client that can be verified on both servers by means of a shared database if that is an option.
During a recent DDoS attack on a DNS, my site was unable to continue to function.
While the main site remained up and running, I was unable to connect to an external API on a different domain, leading the site to become completely unusable.
The data is fetched using PHP:
file_get_contents(API_PATH)
I currently call the API using the domain name, but I'm able to use the IP address if required.
Are there any advantages/disadvantages of calling the API by IP?
Is there anything else I should be aware of before making this change?
Your machine probably cached the resolved host, and has not updated it yet. You would need to flush the DNS cache.
It is not a good idea to use an IP address. While the DNS provider might be attacked, it is more likely that the IP is changed. I mean, rarely is a DNS provider attacked in such a large scale like the recent one, and it is definitely more common to see a website to have its IP address changed (although it shouldn't always happen normally). Therefore, you may want to use an IP address during a DNS attack (although your own DNS provider might be attacked as well), but not as the normal condition. If you want to be safe, fallback to use a cached IP address if the domain fails to resolve; but writing that kind of code is meaningless anyway, since it is rarely useful.
If you use an IP address:
You can't move the service to a different server without updating all the client code
You can't use some forms of load balancing
You can't use the hostname to distinguish between multiple services hosted on the same IP address
There really is not much difference in using the DNS name or IP address in your API calls.
However, If you ever change the service provider, you will have to update both your DNS settings (such as your A records) and the IP address in your code, you would not have to do this otherwise.
Other than that, pretty much good to go, unless someone else thinks of any other reason.
I assume you want to mitigate the impact of the recent DNS DDoS attacks.
Advantages:
Your website still functions. Although that may not matter too much because nobody will be able to even visit your website.
Disadvantages:
What if the API changes its IP address?
What if the API does load balancing using DNS (e.g. it may resolve to different IPs at different times)?
What if the API uses a CDN?
I do not recommend it.
Is there a safe way, to identify a device which might be behind a Router (so the IP is not unique) in PHP?
Background: I have several embedded devices (self programmed & adaptable) which contact a webserver (php+mysql) with status updates. These updates are then - if the source is confirmed - saved to the database.
As I understand it $_SERVER['REMOTE_ADDR'] usually can be trusted (except some IIS configuration where it may - under special circumstances - wrongfully return 127.0.0.1; but different story)
Anyhow since I use SSL, the IP address really should not be a problem, because there a handshake is required and if the IP is faked or simply wrong, the connection should not be established
For now I require IP addresses to be whitelisted by admin, for an status update to be acceppted
The device additionally sends the MAC address via $_POST to identify the different modules with identical IP address (I know this can very easily be forged, and right now will be trusted if the IP address is trusted)
So first of all I am not sure if the IP address in itself is enough for it to be safe from attacks from the outside
Secondly if the device is behind a router, it will have the same IP address as every PC/device on that network. So about anyone there could forge a status update with a fake MAC address (simply as post variable), and since the IP address is whitelisted it will be trusted
So is there any way of confirming the identity of a device, or do you know a better way of doing this?
Aside: Going the other way, and have the webserver poll the different devices might be an option, but since there might be many (> 2000) devices of which we need the very last status (change) I thought it to be inefficient.
IP addresses can be spoofed, MAC addresses can be forged, so theses methods are not sufficient. The general approach is to assign a key to each client device (possibly the same key to all devices, even if this probably a bad idea). The "key" can be anything from a predefined string (weak, think username/password) to a signed certificate (strong, think SSL).
Both can be implemented either at the application level (by PHP) or at server level. If your application runs on Apache httpd server, I would rather recommend using its built-in features as it supports both approaches.
i'm using opencart on a virtual host with a dedicated ip. bank allows virtual pos queries only from dedicated ip, but server ip is used by php to communicate with bank's api. is there any way to force php to use that dedicated ip?
ps: there is a in-code solution, however i prefer more general solution like as php.ini edits.
The proper way is to bind() your connecting socket to the IP address of the interface you wish to use. This will guarantee the behavior you want. (You can set the port number to zero to have the OS choose one.)
You can also make the OS pick the interface appropriately. In fact, I'm surprised it is not. You didn't list any specific IP addresses, interface configurations, or a routing table, but if we assume your private IP is 172.16.0.222 and the bank's IP address is 172.16.0.11, then opening a connecting socket to 172.16.0.11 should use your local private IP address. If it's choosing your public address, then the OS thinks it has a route from that address to the destination. Make sure that is not the case and your problem should be fixed.
In writing a login module, I want to log IP's as an additional measure for verifying who's on the other side is still the same person on the other side.
I'm using $_SERVER['REMOTE_ADDR'] as one (of many) ways to get the remote machine's IP address. Aside from an IPv4 or IPv6 address, are there any other values i should expect this to return?
According to the PHP online documentation only an IP address should be returned.
http://us.php.net/manual/en/reserved.variables.server.php
“'REMOTE_ADDR':
The IP address from which the user is viewing the current page.”
The value can be an IPv4 or IPv6 address. Although you will probably only get canonical values be aware that IP addresses can be written in several ways. 192.0.2.1 is the same as 192.000.002.001, 2001:db8::1 is the same as 2001:0db0:0000:0000:0000:0000:0000:0001, etc. IPv4 addresses can even be written in IPv6 notation like ::ffff:192.0.2.1 or ::ffff:c000:0201 if the webserver accepts IPv4 connections on IPv6 sockets. I see that on Linux systems a lot.
Logging IP addresses should not be a problem as long as you reserve enough space. Actually using IP addresses for access control is getting more and more tricky these days. Because big parts of the world have run out of new IPv4 addresses you will see that ISPs have to use NAT on a large scale to keep connecting new customers to the IPv4 internet. These large scale NATs will use a pool of public IPv4 addresses for maybe thousands of customers. One IP address can be used by many customers, and one customer might end up using different addresses from the pool.
In IPv6 tracking the IP address has other things to take into account. The original IPv6 auto-configuration mechanism is based on using the MAC address as part of the IPv6 address. Because of privacy concerns most operating systems now use a (kind of) randomly generated interface identifier (usually the last 64 bits of the address) for outgoing connections, and those bits can/will can change over time. Some operating systems (Mac OS X) even keep statistics on whether IPv4 or IPv6 is faster and I have seen clients switch back and forth between IPv4 and IPv6 on occasion.
And then you can have users that roam from one wireless hotspot or office network to another, thereby switching IP addresses.
So I think logging IP addresses might make sense based on what you want to do with the data, but using them as (part of) a form of access control might cause more trouble than it's worth.
There's really no added security to checking IP addresses as these can be easily spoofed and anyone who's savvy enough to be intercepting POST transactions is probably doing this anyways.
Also, you may be potentially annoying legitimate users. Think of the instance where a person may be in a location where there are several free open wifi hotspots. When they get to your login page, they may be connected to one hotspot but by the time they sign in, their machine may have decided another router is a better option and therefore their IP will change. Believe it or not, this may deter some (albeit, very few) easily-frustrated users.
Honestly, I just wouldn't bother. Using SSL, if you can, is usually the best way to go to avoid security issues like the one you're describing. Good luck with your project.