I have a web-server that is behind a router. One of the servlets on that server relies on the IP address of the user, however, i often get the IP of my router (i.e. 192.168.1.1) instead of the real IP.
How can i fix that?
It sounds like your "router" is actually acting like a reverse proxy.
It is unlikely that you will be able to solve this in Java ... or even on your server machine. It sounds like a router configuration problem. You might be better off asking for help on "superuser" or "serverfault".
One thing to bear in mind is that identifying clients by IP address is always a bit dodgy. Even once you've sorted out the current problem, the real client IP address may not be available for various reasons:
The client's IP may be NATed.
The client may be talking to your webserver via a series of HTTP proxies.
The client may be spoofing its IP address.
I would suggest that access http://wwww.whatismyip.com to get you IP adddress in case you have not tried that way.You will more idea from this link.
Getting the 'external' IP address in Java
Grab your global IP from http://www.whatismyip.com/ , I think you might also need to configure port forwarding on router of user that is having servlet.
Related
I want to simply connect two machines on the same network via a TCP Server/Client socket connection.
Right now, I need the IPv4 address from the machine hosting the server in order to connect the client.
localhost works fine when I'm running the server and the client on the same computer, but that's not very useful.
Is there any way around having to manually punch in the IPv4 of the host computer?
Thanks, this will probably clear up a lot of confusion.
Use a broadcast to send all clients a message. (this could contain the servers IP but think about that! it could be a security issue)
There are good examples on sending broadcast messages with java
Broadcasting to Multiple Recipients
If you know the name of the hosts, then you can also pass these names in a config file and use getaddrinfo() to get the IP address of the host: http://man7.org/linux/man-pages/man3/getaddrinfo.3.html . Since hostnames do not chnage frequently, this should provide good improvement as compared to manually punching the IP address.
I'm developing a Spring application on my Windows 7 machine and running it on localhost:8080.
Is there any chance that if I do this in a public location like Starbucks that it is possible for my app to be visible to others?
(I'm using Windows Firewall and Microsoft Security Essentials)
Be sure that it is binding to localhost:8080 (i.e., 127.0.0.1), not all interfaces (which is probably the default). Server programs usually have an option to say which IP addresses to bind. For example, in Apache, you can provide an IP address to the Listen directive in addition to a port number. If you only bind to 127.0.0.1, the port will not be open for people scanning your external IP address.
Short answer: No.
Long answer: Someone might access your app like this:
If you visit a malicious website (if anyone at Starbucks is poisoning the DNS cache or spoofing DNS responses then you may visit a malicious website at www.google.com not knowing about it) then the attacker may send you to his domain with a DNS server (which may in fact be on his laptop) replying to the same query with very short TTL once with his IP, then with 127.0.0.1, then his IP again, etc. That way when you are sent to (http://www.example.com:8080) it is resolved as the attacker's IP and you get the website which starts an AJAX request to the same domain and the same port (so the same origin policy is satisfied in every browser) but thanks to the short TTL you don't have the domain entry in your cache any more, so you ask again and this time you get the answer 127.0.0.1 which incidentally is your own loopback interface which you assume to be invisible from the outside - and it is in fact invisible from the outside but perfectly visible from your browser. Your browser will happily connect to your app at 127.0.0.1:8080 and proxy the request to the attacker with another AJAX connection or any other side channel. Voilà, your app is now connected to the world!
Things like this happen in the wild so be careful. Sometimes people even access admin interfaces in routers behind NAT and firewalls that way. Quite frankly I'm pretty scared by all of the responses telling you that it is impossible to access anything running on localhost. Be careful what you do.
Is there any chance that if I do this in a public location like Starbucks that it is possible for my app to be visible to others?
Of course! People can look over your shoulder.
what Jeremiah said. use netstat -an to check what addresses it bound to.
and never trust Windows firewall, or any other software to which you don't have the source.
If the port is open it can be. If you program it to only accept connections from localhost while developing then even if they can see it, they wont be able to connect to it.
I have a database application (or search engine) which is called Solr.
I connect to it via port 8983.
I do this from PHP code, so I add and remove records from it via php.
On my server I have a firewall.
I have set this firewall to only allow connections to and from this port (8983) from the ip address of my own server. In other words, only allow servers IP to access this port.
Is that safe? Or am I thinking all wrong here? Will others be able to "simulate" my ip address and act as the server?
This is because otherwise others may add/remove records as they want from their own IP addresses...
Thanks
It might be a good idea to also block all outgoing traffic from port 8983 on the server to anywhere but your own server's IP address. This, in addition to dropping any packet to that port not from your server, will doubly ensure that, even if someone is somehow able to modify the daemon listening on port 8983 on the server, allowing it to mirror traffic to another host, it would be dropped before it leaves your computer.
Yes, you are safe as long as no one gains control of your local server.
You can also cause Solr to bind to the "localhost" or "127.0.0.1" adapter as opposed to "0.0.0.0", which would have a similar effect. It never hurts to layer the firewall above that just in case the configuration is messed up.
You would not be safe if you are worried of tampering from the same network. There are many situations where the real threats are from inside the network, not from some script kiddie a continent away.
I agree with theatrus to use only localhost.
If you are deployed on multiple hosts there are several ways to create a secure tunnel, e.g
ssh -l 8983:localhost:8983 solr.server
this will create a secure tunnel. (Although it takes non trivial CPU when the bandwidth is high). There are also other solutions.
An additional advantage is that for a developer you can use a sample solr server locally and your code in your IDE, and it will just work with the same config as in production. The less that needs to be changed when deploying, the better.
This is safe. The ip address used in a TCP connection because of the three way handshake. This is a good firewall rule-set, but you should always test your rulesets with nmap.
What you do have to worry about is running an open proxy server on the server that is executing the PHP.
I have a Java application that registers a server component in a service provider, and then sends the service name to a client. The client uses the service name to get an address out of the service provider to the server. However, the server has several interfaces only 1 of which the client get get at, so the service must be registered with the right IP. We discovered the client through a broadcast, so I have the client IP and an Enumeration of the computers network interfaces. How do I match the IP to an interface, not knowing what the netmask of the client IP is?
Spontaneously I imagine turning all the addresses to ints and chomping the local ips with their netmask and looking for a 'best match', but I wonder if there is a better way?
(this is an enterprise(tm) solution, so cutting out the service provider isn't an option, at least not w/o a political campaign first ;) )
By my understanding, the service provider has interfaces on multiple distinct networks. Each client is on only one of those networks and thus can only communicate with one of the interfaces. The service needs to discover which of the interfaces is accessible to the client so that it may send the correct address. You (the service developer) have no control over the network environment into which the service is deployed and thus cannot employ network-level solutions such as DNS.
In many network setups routing is symmetric. That is, the route from host A to host B is the same as that from host B to host A. If you know this to be the case in all environments to which your service will be deployed then you can safely assume that the address used to connect to the client is accessible to the client. That address could be discovered, for example, by connecting a DatagramSocket to the client and then calling its getLocalAddress() method.
If routing is asymmetric I know of no way to determine whether a particular interface is accessible to the client using only the java.net API. If you control the client implementation you might be able to have it include the broadcast source address (which should be the server interface visible to it) in its broadcast response packet. Beyond that, you haven't included enough information about the scenario to give specific advice. For example, it would be useful to know what protocol is used for the broadcast advertisement and client response thereto.
This depends on how you are going about this.
Sample code much?
There is a a ".getHostAddress()" method for InetAddress which might be useful.
This is usually done using DNS. The interface should be listed in DNS so you can reach it by name rather than address servicehost.example.com rather than 192.0.2.42.
It is more a network administration issue than the application.
Consider the server (hosting the java application) is multi-homed.
it can be three address:
1. 99.88.77.66 (Public IP)
2. 10.10.10.10 (Private, Internally assigned IP)
Which IP will your potential client can get access depends on the network configuration.
The client may access from a public IP, but it will access your private IP due to NAT.
Another example, may be your client IP is 192.168.10.10, through NAT, it access your 10.10.10.10 IP.
You cannot calculated the correct IP (to publish your service) by any kind of prefix matching.
You have mentioned that, it is an enterprise solution, and complex network configuration is common in such kind of environment.
With DNS, your server host may be myapp.company.com
It is is up to the DNS facility to resolve the correct IP for the client.
You may need to get coordinate with networking guy, with proper support in DNS,
the solution should be trivial and more robust.
This might be one of those "huh, why?" questions, but I figured it would be worth the try.
How would one, from a server-side application, use the clients IP address as the applications IP address to another website? The basic idea is that any work the server side application does, is seen as the client itself doing the work, and not the servers static IP.
I am not sure if changing HTTP headers would work, but I could be wrong. Is there any documentation out there on this?
Thanks,
Kyle
Utterly, utterly impossible. You won't even be able to open a TCP connection because the other website's server will try to handshake with the client, and fail.
An IP address isn't just any old ID, it's the actually address that servers will send any response to. Spoofing it basically only makes sense if you can fit your request into a single IP packet (which rules out TCP and thus HTTP) and are not interested in the response. Even then it can fail because your ISP's routers may have anti-spoofing rules that drop packets with "outside" IP addresses originating from "inside" networks.
Why on earth would a legitimate application want to spoof its IP address?
Changing HTTP headers might cut it, but most likely it won't. Depends on how naive the other server is.
It sounds like you're trying to do something the wrong way, can you give a bit more information as to what exactly the use-case is?
If there's no processing to be done in between, you can do port forwarding on your server's IP firewall, so the client connects to your server but ends up talking to the other server.
If there's more involvement of your server, then the correct thing to do would be to pass the client's IP to the other server as part of the URL (if it's a web app) or elsewhere in the data (if not) so the receiving server can know and correctly log the process without any need for fakery. Of course this would also call for a change in the other app.
Again assuming we're talking about HTTP, another idea that came to my mind would be to redirect your client to the other server. As long as all necessary data is in the URI, you could advise the client's browser to connect to the other server with a URI of your own creation that could carry whatever extra value your server's processing adds to the request.
Decades ago, the designer of internet asked, "how can we prevent Kyle Rozendo from doing such a devious thing?"
If the client is cooperating, you can install some software on client machine, and do the work from there. For example, a signed java applet on your page. [kidding]If the client is not cooperating, install some trojan virus[/kidding]